On Monday 02 of April 2012, Michael Meeks wrote:
> On Fri, 2012-03-30 at 15:21 +0100, Michael Meeks wrote:
> > I up-loaded the output of my string debug for a writer start:
>
> And discovered there was a bazillion problems with it, in particular
> the handling of OUStrings, having nailed that - it now has some
> considerable error due to 'String' handling; nevertheless a new version:
...
> How we get 81k allocations of a string containing '/' is somewhat
> curious ;-) possibly we want to have a table of static one-char ascii
> strings for the one character entries - to save atomic ref-counting
> thrash, and pointless often transient allocations.
>
> Interestingly, all these top uses are newish; when I last did the
> stats. As a rather less reliable dump: (due to the unreliable use of
> String classes I think) - I find it hard to believe we have 19k live '/'
> strings - does anyone feel guilty about that ? [ actually, I'm just
> poking at the configmgr code which looks like it might be the culprit ]
I don't want to spoil the fun much for you :) , but I expect the number of
string allocations to go down when RTL_CONSTASCII_* stops being used in favor
of string literals, and further down after whenever I get to implementing the
efficient operator+. So you may be profiling a problem for a part of which a
solution already exists.
Grepping configmgr/ for "/" shows things like
nodepath = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("/")) + nodepath;
where the / string instance can be avoided completely. My changes won't do
anything about the long-lived / instances though, so there indeed one shared
instance may take care of all of them.
--
Lubos Lunak
l.lu...@suse.cz
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
