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

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@suse.com  <><, Pseudo Engineer, itinerant idiot

Attachment: strings.pl
Description: Perl program