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

[Michael Meeks]

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:

	http://www.gnome.org/~michael/llog4.txt.gz

	is up;

	re-running that shows:

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

  81840 +/
  41125 +IMPLEMENTATIONS
  36468 +/IMPLEMENTATIONS/
  35796 +/IMPLEMENTATIONS
  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
1920    
689     en
650     Normal
559     void
347     com.sun.star.uno.XInterface::release
347     com.sun.star.uno.XInterface::queryInterface
347     com.sun.star.uno.XInterface::acquire
249     x-default
241     Regular
224     /UCR
219     com.sun.star.i18n.Transliteration.l10n
209     IMPLEMENTATIONS
200     com
194     com.sun.star.loader.SharedLibrary
194     -甭
175     ALIEN
169     IMPORT
159     boolean
156     Bold
154     EXPORT
142     com.sun.star.uno.XInterface

	Interestingly the "com.sun.star" 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:

+
+/d
-/d
+/data/
-/data/
+/data/opt/OOIn
-/data/opt/OOIn
+/data/opt/OOInstall/program/oo
-/data/opt/OOInstall/program/oo
+/data/opt/OOInstall/program/oosplash

	in the URI handling code ;-) trivially fixed.

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

+SINGLETONS
+com.sun.star.deployment.thePackageManagerFactory
+/SINGLETONS/
-/SINGLETONS/
+/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory
-SINGLETONS
-com.sun.star.deployment.thePackageManagerFactory
-/
-/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory
+/
+SINGLETONS
+com.sun.star.deployment.thePackageManagerFactory
+/SINGLETONS/
-/SINGLETONS/
+/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory
-SINGLETONS
-com.sun.star.deployment.thePackageManagerFactory
-/
-/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory

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

$ zcat /tmp/llog4.txt.gz | grep +/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory | wc -l
159

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

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

	ATB,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strings.pl
Type: application/x-perl
Size: 630 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120402/858a8d55/attachment.bin>