Apache OpenOffice (AOO) Bugzilla – Issue 115684
svl: performance regression in SfxItemPool
Last modified: 2017-05-20 10:22:08 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.
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.
We must make sure that there is not pointers to vector container. http://en.wikipedia.org/wiki/Vector_(C%2B%2B)#Capacity_and_reallocation
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.
fixed in CWS tl77 http://hg.services.openoffice.org/hg/cws/tl77/rev/5dde9850d569