<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - FILEOPEN: slow loading in minutes of .ods and .xlsx with >1000 of conditional formats, also dump" href="https://bugs.documentfoundation.org/show_bug.cgi?id=81765#c28">Comment # 28</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - FILEOPEN: slow loading in minutes of .ods and .xlsx with >1000 of conditional formats, also dump" href="https://bugs.documentfoundation.org/show_bug.cgi?id=81765">bug 81765</a> from <a class="email" href="mailto:noelgrandin@gmail.com" title="Noel Grandin <noelgrandin@gmail.com>"> Noel Grandin</a> <pre>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</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>