Re: How to measure effects of OUString::intern ?

On Mon, 2013-07-29 at 23:59 +0200, Mark Wielaard wrote:
> That seems to make sense that this is about image paths. Most paths seem
> to come from opt/share/config/images.zip. But that file contains 3800+
> entries and only a few seem to be reused later.

        Ho hum; I'm sure that we keep that images.zip open all the time - so if
those strings are not in memory and are only temporaries, then other
ones will be; interesting.

> I am tempted to. Will do some more testing first to make sure I am not
> missing something.

        I think you're good :-) I'd just push it.

> >     The reason it was added was for images.zip - if the package code has
> > improved then we should take & save that space/time.
>
> I haven't yet found the code which references the image/resources
> maybe it needs interning itself. But it certainly looks like the current
> code is a bit too eager interning everything.

        So  that is vcl/source/gdi/impimagetree.cxx see ImplImageTree::find or
somesuch.
 
> >     I'd dump the ref-count + string contents of the intern table to see if
> > there is more wasteage.
>
> I'll try that next. For now I used systemtap which happens to have utf16
> user string support. It looks all interned strings go through the function
> rtl_ustring_intern_internal. So probing that and printing the string gives
> an interesting overview.

        :-) great; looks like we have a load of stuff that shouldn't be hanging
around there - as you say - a ton of that is these zip URLs ;-)

> >     You saw the OUString debugging code: RTL_LOG_STRING_NEW /
> > _STRING_DELETE etc. that can produce a long but crunch-able set of
> > printfs on stdout: many of which are sadly not that useful due to
> > OUStringBuffer mutation (IIRC - but presumably some more work could
> > clean that up).
>
> I hadn't seen that yet, but that might be useful to see which strings
> are recreated multiple times and so are candidates for interning.
> Is there already code to enable/trigger RTL_LOG_STRING_NEW?
> Or should I just write my own hooks?

        I guess you just write your own fprintf(stderr,) etc. in the strimp.hxx
header ? of course, converting them to UTF8 and printing them is a bit
of a PITA since strimp.hxx is used in both 8bit and 16bit strings.

        Anyhow - thanks so much for digging into this lot ! :-)

        ATB,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot