string / size bits ... #2 ...

[Lubos Lunak]

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.lunak at suse.cz