[Libreoffice-bugs] [Bug 81765] FILEOPEN: slow loading in minutes of .ods and .xlsx with >1000 of conditional formats, also dump

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=81765

--- Comment #28 from Noel Grandin <noelgrandin at gmail.com> ---
Attaching the IRC discussion of this problem 

May 02 14:10:15 <noelgrandin>   so of the items we stick into pools we modify
all over the place
May 02 14:10:20 <noelgrandin>   s/so/some
May 02 14:10:39 <mst___>        noelgrandin, that sounds very wrong
May 02 14:11:44 <noelgrandin>   mst___, ScPatternAttr 
May 02 14:12:17 <noelgrandin>   and of course there are the SvxFieldItem things
that editeng likes to modify
May 02 14:12:29 *       mst___ is surprised that such horrible abuse of
interface contract is in sc, not sw...
May 02 14:13:12 <noelgrandin>   I think its a case of (a)busing the
de-duplicate functionality they have
May 02 14:13:25 <erAck> noelgrandin: where does that modify items in the pool?
May 02 14:14:27 <noelgrandin>   erAck, ScPatternAttr ends up in a pool, and
ScPatternAttr extends SfxSetItem, and lots of places (1500+ lines) call
GetItemSet() on it and modify stuff inside it, and it's operator== is dependant
on it's contents
May 02 14:17:00 <noelgrandin>   which was not a problem when the code would
always scan all the ScPatternAttr's in a pool to find a match, but as soon as I
tried to make the scanning smarter...
May 02 14:19:21 *       erAck doesn't quite understand.. and doesn't have time
to spend hours to dig into it now
May 02 14:21:11 <noelgrandin>   erAck, pool contain items, and when we add an
item, we attempt to match against an existing item (de-duplicate for memory
saving I guess). that process of matching becomes O(n^2) when loading certain
documents. I made the scanning faster by sorting the list. But that sorting
fails because various code likes to modify the ScPatternAttr that are inside a
pool, resulting in an unsorted list inside the pool
May 02 14:23:44 <mmeeks>        noelgrandin: perhaps good to have some
stack-traces from a hardware watchpoint of the state being changed (?) =)
May 02 14:24:59 <noelgrandin>   mmeeks, it gets changed from tons of places, I
have a 1500+ line patch where I tried to move the changing inside the class so
I could trigger a manual re-sort of the cached items in the pool.
May 02 14:25:02 <erAck> noelgrandin: so what you call a pool is actually the
SfxItemSet?
May 02 14:25:20 <noelgrandin>   erAck, no, the SfxItemSet is itself also an
item in a pool 
May 02 14:25:41 <noelgrandin>   erAck, sorry, that should be SfxSetItem (which
contains an SfxItemSet)
May 02 14:25:53 <noelgrandin>   all rather confusing
May 02 14:27:10 <noelgrandin>   anyhow, just a load-time perf improvement,
backing it out no big deal

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20190503/4e98940b/attachment.html>