Re: string / size bits ... #2 ...

To make it easier to find culprits, perhaps you could add a feature to 
your script?
Use some kind of variable to select a specific string, and then store 
the callstack every time that string gets allocated, using backtrace()
Then dump the top 100 call-stacks using backtrace_symbols()

Brute force maybe, but it would make it easier to find the source(s) of 
the problems.

On 2012-04-02 16:25, 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:
>
>         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.
>
>
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

Disclaimer: http://www.peralex.com/disclaimer.html