Michael Meeks wrote:
Hi Kay,
On Thu, 2006-08-31 at 18:15 +0200, Kay Ramme wrote:
would you mind to reiterate the potential / real savings and costs for
me? Admitting that I have not understand your explanations the first
time ... ;-)
Sure; simple enough. My analysis of duplicate strings (for a quiescent
writer) is here:
http://go-oo.org/~michael/ustrings.ods
It shows >90% of our OUStrings (by memory used) are duplicates of other
OUStrings - so we're burning >1Mb here pointlessly. I've been going
around fixing some of the specific worst-offenders here.
In many cases these are plain-and-simple ASCII constants used as cnames
to denote fields, property names etc. These are typically constructed
with the normal RTL_CONSTASCII_VERYLONGMACRONAME("foo") type
constructors, which generates a new copy every time, hence the
duplication.
The proposal is to use an always-growing, non-aged, hash of such common
strings; and a nice constructor something like:
Not sure whether the "always-growing" is a good idea (esp. in sal, which
is somewhat application agnostic and serves as the basis for not only
the soffice binary; even if the maximum size were reasonably bounded for
soffice in real life, it need not be for other applications).
rtl::OUString rtl::OUString::fromCName(const char *foo)
[ or whatever ], that will avoid the need for ugly macros (we have to
iterate to hash the string anyway), and will return the same value as
last time.
Btw, a template parameterized on the size of an array argument would
also serve to determine the size of the passed in (literal) string
without time overhead.
-Stephan
Performance wise this should ~always be a win: of course we need to do
1 hash lookup, (with a lock taken I guess), but the current situation of
expensive memory allocation, copying etc. is no doubt rather slower.
And, of course - we can save again when doing comparisons 1st by pointer
value.
We'd need a simple hash table impl. in sal/ though that'd be fairly
easy to hack up [ it'd be hard to produce something worse than stl's
effort ;-]. What do you think ?
Regards,
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
