https://bugs.freedesktop.org/show_bug.cgi?id=38513
Michael Meeks <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|[email protected] |[email protected] |desktop.org | --- Comment #11 from Michael Meeks <[email protected]> --- Created attachment 100598 --> https://bugs.freedesktop.org/attachment.cgi?id=100598&action=edit prototype speedup patch So - this is an interesting problem; there are several horribly intermittent performance problems here. It seems that the SfxItemPool management is extremely performance fragile. In particular for non-poolable items - if we happen to add and remove them in the right order (which sadly we do per element in response to SAX callbacks [!] ) - actually just for one type 'SwFmtCharFmt' - I assume because it's an SwClient sub-class then we can either be 'lucky' or not ;-) The basic problem is that if when we add our temporary element there is a hole at the front of the SfxPoolItemArra_Impl vector, then we will add it there, append the new element to the end of the array, and then remove the first element again [ thus forcing a re-scan of the whole array to find the next hole - which is the expensive bit ]. The attached patch uses an unordered_set for the SfxItemPool - that should have a linear cost for add/removes of non-poolable items - and indeed it significantly helps with performance. With this patch I get a 61 second load instead of a 290 second load; which is a win. Of course, inevitably it breaks a unit test as well so not to master. Perhaps there is a simpler / less invasive way. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
