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.