Issue 115684

Summary: svl: performance regression in SfxItemPool
Product: General Reporter: mst.ooo
Component: codeAssignee: mst.ooo
Status: CLOSED FIXED QA Contact: issues@framework <issues>
Severity: Trivial    
Priority: P3 CC: gang65, issues, lars.langhans, Mathias_Bauer
Version: DEV300m92   
Target Milestone: 3.4.0   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

Description mst.ooo 2010-11-19 16:39:42 UTC
lla alerted me to a regression in performance that was introduced in m92
and is apparently caused by the svarray CWS:
storing the performance test document in writer is 9% slower on linux, 20%
slower on windows.

fortunately the documents written by m90 and by svarray are not different,
so it is not caused by writing wrong stuff.

so i investigated with callgrind:
storing the document takes #cycles (or whatever callgrind counts):
m90:      5,335,595,338
svarray: 6,336,979,732

looking at the profile with kcachegrind i found something very surprising.
the SfxItemPool::Remove() and SfxItemPool::Put() methods are much slower.
numbers for SfxItemPool::Remove():
m90:      167 million
svarray: 643 million
(Put() is similar)

the difference is almost entirely due to the operator++ of the iterator
of the deque that holds the items.
this takes 408 million cycles in svarray.

then i replaced the deque with a vector, and the number for
SfxItemPool::Remove() was:
188 million

so it's almost as fast as before.

it's very surprising that the deque iterator is so slow;
in further changes we should check if vector is sufficient and only use
deque if both ends of the container are manipulated.
Comment 1 mst.ooo 2010-11-19 16:48:31 UTC
oh, forgot the number for the whole storing the document with the vector instead
of deque:
5,340,828,925

so the difference to m90's 5,335,595,338 is negligible.
Comment 2 gang65 2010-11-19 18:09:12 UTC
We must make sure that there is not pointers to vector container.

http://en.wikipedia.org/wiki/Vector_(C%2B%2B)#Capacity_and_reallocation
Comment 3 mst.ooo 2010-11-19 18:41:07 UTC
yes, iterators to vector may get invalidated.
i couldn't find a problem in the SfxItemPool due to that.

generally for vector it may be better to store an integer index instead of iterator,
the index would survive reallocations.
Comment 4 mst.ooo 2010-11-23 11:09:19 UTC
fixed in CWS tl77
http://hg.services.openoffice.org/hg/cws/tl77/rev/5dde9850d569