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

Michael Meeks michael.meeks at
Mon Apr 2 07:25:58 PDT 2012

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:

	is up;

	re-running that shows:

$ zcat /tmp/llog.txt.gz | grep '^+' | sort | uniq -c | sort -n -r | head -n 10

  81840 +/
  29744 +UNO
  11341 +SERVICES
  10331 +ACTIVATOR
   7167 +en-US
   6669 +
   5204 +LOCATION

	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 ]

37209 live strings remain at end of log

copies	string
19011   /
5910    en-US
689     en
650     Normal
559     void
249     x-default
241     Regular
224     /UCR
200     com
194     -甭
175     ALIEN
169     IMPORT
159     boolean
156     Bold
154     EXPORT

	Interestingly the "" string shows up 286k times in the log
of alloc / deletes - oh for the day that we can stop pushing that around
as UCS2 in memory.

	Anyhow - so far, I saved 1% of our memory allocate / free's by fixing
the (busted IMHO) rtl URI encode/decode - with a ~4 line patch :-) which
is encouraging, that was just noticing this:


	in the URI handling code ;-) trivially fixed.

	There are lots of other instances of ineffiency visible here though eg.


	repeated a dozen+ times back to back for no obvious reason :-)

$ zcat /tmp/llog4.txt.gz | grep +/SINGLETONS/ | wc -l

	We seem to do this dozens of times for each of our singletons, and so

	Of course, the log is by no means perfect, but hopefully it shows
something useful :-)



michael.meeks at  <><, Pseudo Engineer, itinerant idiot
-------------- next part --------------
A non-text attachment was scrubbed...
Type: application/x-perl
Size: 630 bytes
Desc: not available
URL: <>

More information about the LibreOffice mailing list