The document https://bugs.freedesktop.org/attachment.cgi?id=58807 linked from bug#47644 when loaded (please use master for the OLE2 speedups), then proceeds to have a 15 second hang while it is doing layout. Since we're just looking at the first page when that is done, it makes you wonder: why are we blocking the user this long, can't we do an incremental layout of some kind ? I attach a callgrind profile of the startup + load (startup vanishes into the random noise).
Trace at: http://users.freedesktop.org/~michael/callgrind-slow-doc-load.txt.bz2
Seems most of the aggravation (~75%+ of the time) comes from: if( pWrtShell->GetDoc()->IsUpdateExpFld() ) { SET_CURR_SHELL( pWrtShell ); pWrtShell->StartAction(); pWrtShell->CalcLayout(); pWrtShell->GetDoc()->UpdateFlds(NULL, false); pWrtShell->EndAction(); pWrtShell->GetDoc()->SetUpdateExpFldStat( sal_False ); } So - I guess, being able to defer more of that, to not do it synchronously would be rather nice ;-)
For a complete start, parse, layout cycle - without the sync. layout I get a 6 second load, with it I get a 24 second load. Hopefully we hit that path reasonably infrequently but even so; surely many kinds of field we can update asynchronously as the data changes [ though I guess that can trigger re-layouts itself but we must have this problem already ].
Created attachment 61603 [details] if we import no ww8 fields, don't force layout post load So - the attached is a pretty grisly one - since it's specific to ww8 - whereas we have the same problem here all across the filter code. Ideally we should maintain a count of the number of each type of field we actually have in the writer core, and be able to know which of these we actually need to force this CalcLayout for in SwView - I suspect few require this. OTOH, this captures the 6 second load of that slow .doc document, and I've tested that it does the sync. layout if you do have fields there. Thoughts appreciated.
Caolan, Cedric - thoughts ? [ and for -3-5 ? ]
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cb235067de2bf7feef3c03eeb08492e60da0d083 Resolves: fdo#49897 add+use SwDoc::containsUpdatableFields
How about the above commit ? More generic across filters, dunno if it makes sense to burrow down into the updateable fields, most are updateable I guess. Most big docs are going to have a page-count/page-number fields at least so this mightn't be massively useful in the general case, but *looks* on the face of it safe anyway ?
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=30f84257b34eb956027c21934ec9fa63cb25fcf4&g=libreoffice-3-5 Resolves: fdo#49897 add+use SwDoc::containsUpdatableFields It will be available in LibreOffice 3.5.4.
Lovely, gave it a whirl; yes it's a shame that larger docs are more likely to have eg. page-number fields, I guess we need to do more work in future to make them update pleasantly and asynchronously as the document is laid out - nevertheless, simple documents big and small should load a little faster. Pushed to -3-5 - thanks ! :-)