Issue 115684 - svl: performance regression in SfxItemPool
Summary: svl: performance regression in SfxItemPool
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: DEV300m92
Hardware: All All
: P3 Trivial (vote)
Target Milestone: 3.4.0
QA Contact: issues@framework
Depends on:
Reported: 2010-11-19 16:39 UTC by
Modified: 2017-05-20 10:22 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description 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 2010-11-19 16:48:31 UTC
oh, forgot the number for the whole storing the document with the vector instead
of deque:

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.
Comment 3 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 2010-11-23 11:09:19 UTC
fixed in CWS tl77