On 21/12/12 17:55, Michael Meeks wrote:
> There are probably better ways to do this :-) clearly it would be nice
> to manage layered SfxItemSets via UNO in an even more performant and
> elegant way that doesn't rely on great big uno PropertyValue sequences
> getting sent repeatedly and so on. Anyhow the attached gives a
> reasonable win on RTF import: 25% faster or so. It's hard to see how it
> could make things much perform worse.
wow - i've always suspected that it's unnecessarily slow to set these
items in the model one at a time, when there is a InsertItemSet
available, but 25% faster import with this single change is impressive.
there may be more places where a similar approach could be applicable,
both in API implementations in sw and in writerfilter/xmloff import
code, e.g. see cc99bb9f383a65912d004e227a5b6a88b401bbba which was purely
result of me debugging some crash and wondering why a certain insert
method in sw core is called so often (in that case sw API impl. actually
did the right thing).
> It has a FIXME - I'm unclear
> exactly what's going on there. Clearly I'm wandering at the edge of my
> competence wrt. the writer bits here, so help/encouragement appreciated.
> + // FIXME: unclear that we need to do this really ...
> + if (!rCursorMap.getByName(
> rCharacterAndParagraphProperties[nProp].Name ))
> {
> - sMessage = rIllegal.Message;
> bIllegalException = true;
i suppose this exception would be thrown by
SwUnoCursorHelper::SetPropertyValues now anyway... which is actually a
problem because in that case
m_pImpl->m_pDoc->GetIDocumentUndoRedo().EndUndo(UNDO_INSERT, NULL);
won't be executed and we get a confused UNDO stack in writer...
i guess it's best to move the Start/EndUndo into
SwUnoCursorHelper::SetPropertyValues to fix that (can't be omitted
entirely since it's possible that multiple different Undo objects are
created).
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
