[Libreoffice] in-lining more UNO foo ...

[Michael Meeks]

Hi Matus,

On Thu, 2011-05-26 at 17:47 +0200, Matúš Kukan wrote:
> >        _copyConstructAny( pDest, pSource, pType, 0, acquire, 0 );
>
> So _copyConstructAny is called 180 205 times mostly from
> uno_type_any_construct. I think inside the function itself are
> executed 0.26% instructions of all.

	I get a cumulative counts (for a writer startup and shutdown) of:

1.4%	uno_type_any_construct
1.5%	uno_any_destruct
1.1%	uno_type_any_assign

	which I rather suspect are not overlapping; giving 4% of our startup
doing boxing and un-boxing. I'm not certain that we capture the true
evil of the underlying 'store_' code doing type reads / writes there.

> There is also Cycle Detection option in KCachegrind but I don't know
> what it is doing. I had it enabled.

	:-)

> I guess time can't be measured from callgrind's output. Or cycle
> estimation is something like that?

	Well - I guess we need to do more; now I look at KCachegrind again - I
am once again irritated by the characterisation sorted by shared library
[ I'd love you to look into fixing that ]: I get:

23 %	libuno_sal.so.3
17.5%	libc-2.11.3.so
12.2%	configmgr...
10%     ld.so.

	And my problem is - I have no idea -who- is using libc too much :-)
what if the 12% of configmr causes 50% of the libc wasteage and 50% of
the libuno_sal wasteage ? :-)

	It would be really nice to be able to mark some libraries as
'optimal' (eg. glibc - there are ~no wins possible in there), and then
accounting the cost (and colouring in the map) of their methods calls to
the next library up.

	That would let us (eg.) mark configmgr as optimal (though it is not) -
and see which libraries higher up the stack are (perhaps) mis-using it.

	Beyond some extra UI, hopefully that is not horribly difficult to
achieve (?). And we should prolly focus on that first [ another first -
sorry - but it is really is the bottom of the stack ;-].

	Thanks,

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot