Michael Meeks wrote:
Hi there,
So - in my ongoing campaign to shrink memory usage, it seems that the
cppuhelper classes use the (uber-stupid) stl::hash_map code that insists
on allocating a staggering amount of memory for an empty hash (as
previously discussed).
Dumping counts of OMultiTypeInterfaceContainerHelper and it's
Int32 variant extant post writer startup I see:
IfContainers 507
IfContainersInt32 388
I also notice that wrt. the contents of the m_pMap we normally
have very few elements:
count num elements
282 1
2841 2
1569 3
38 4
That is for IfContainers, and -incredibly- none of the
IfContainersInt32 actually have any contents at all ;-) [ I have to load
an impress document to get even a few of them with 1-2 items in them ].
A hash_map's default size is 193 elements, so we waste:
(507+388) * (193 - 4) * 4-bytes-per-ptr = 676Kb
The patch:
http://go-oo.org/ooo-build/patches/src680/size-cppuhelper.diff
switches from a hash to a vector, which given the size saving, and
small data sets, will almost certainly accelerate things however you
look at it, and saves a chunk of RAM.
The saving is around 700k by not allocating the (~all empty) Int32
container contents too, numbers from pmap (DIRTY):
Before: 19264 19256 + 19268 + 3 / p : 19262
After: 18552 18552 + 18544 + 3 / p : 18549
Saving: - p : 713(k)
"using STL hash may unexpectedly bloat your world" :-]
Be specific in your finger pointing. ;) There is no STL, and there is
no STL hash. There is C++ and there is STLport hash_map. I vaguely
remember you once tried to attack this space-waste problem of STLport
hash_map more generally by modifying the STLport used by OOo; what has
become of that?
This does of course change some cross-module API - wrt. the inlines in
interfacecontainer.hxx - but I believe this is no longer a big concern
(?).
As far as I see, the patch attached to
<
http://www.openoffice.org/issues/show_bug.cgi?id=72766> only changes
the all-inline class template
cppu::OMultiTypeInterfaceContainerHelperVar, so that should be OK.
-Stephan
Thanks,
Michael.
