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

[Michael Meeks]

Hi Matus,

On Sun, 2011-05-22 at 13:58 +0200, Matúš Kukan wrote:
> This week I've finished playing with commandimages. Result is about
> 70kB (cca 3%) save in size of images*.zip.

	Nice - so, 3% doesn't sound like much - but the in-memory cost of
duplicating all those path strings is quite large. Here is how progress
looks to me:

lo ver	tango size	directory size
3.3	4.0Mb		262k
3.4	2.5Mb		136k
3.6	2.4Mb		96k

	I think the directory strings may be duplicated twice at run time, in
RAM, with some allocation overhead (for some fun reasons) - so it is a
real win - perhaps 1/4 a Mb or so - but, by now the returns are
diminishing from this I think.

> Unfortunately I'm not yet finished with my bachelor's thesis and
> cannot work on Libreoffice 8hours/day next week.
> Next could be merging libraries into larger ones.

	Hey ho - I had a quick look at that, it seems a tad tricky, wrt. the
dependency graph and the gnu-make-isation; so perhaps skipping that and
looking at the IDL compiler problem might be nice [ warning this is a
bit more involved ;-].

	The basic problem we have here is this, code like:

    PropertyValue aPath;
    aPath.Name = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("nodepath"));
    aPath.Value <<= rtl::OUString::createFromAscii( "foo" );
    pArgs[0] <<= aPath; // This is the problem line ...

	despite us knowing all the information to do this 'right' at compile
time, ends up loading a huge (and horribly inefficient) types.rdb file,
and then using that to copy C++ types into an abstract internal
representation.

	Of course - it'd be nice to have a profile to see if this is actually
slow first ;-) can you run kcachegrind[1] on a small document load ? and
look at the call counts of things like:

        _copyConstructAny( pDest, pSource, pType, 0, acquire, 0 );

	Instead, of course, we want to create constructors - I'd do this
manually at first - that extend:

	cppu/inc/com/sun/star/uno/Any.hxx 's built-in operators.

	apparently we only have a single in-lined assignment operator for bool
(odd), no idea why that is ;-)

	But that aside; when we do:

inline void SAL_CALL operator <<= ( Any & rAny, bool const & value )
    SAL_THROW( () )
{
    sal_Bool b = value;
    ::uno_type_any_assign(
        &rAny, &b, ::getCppuBooleanType().getTypeLibType(),
        (uno_AcquireFunc) cpp_acquire, (uno_ReleaseFunc) cpp_release );
}

	For PropertyValue - then we go do this heavy lifting to populate the
type information.

	I suspect we want either:

	a) to pass the type information in ourselves in some
	   simplified form for simple structs: perhaps just a vararg
	   ::uno_type_any_assign_ext (as above, ...);
	   where we can take POD types
or
	b) unwind the structure that the Any uses internally - we
	   might hope that it matches the C++ ABI I suppose, so we
	   could do this simply - and then in-line an assignment
	   to do that perhaps

inline void SAL_CALL operator <<= ( Any & rAny, PropertyValue & value )
    SAL_THROW( () )
{
    ::uno_type_allocate_magic_fn (&rAny, ::getCppuType(&value));
    PropertyValue &rProp = (PropertyValue &)rAny.value_data;
    rProp = value;
}

	or whatever such magic we can achieve ;-) Either way it requires some
digging around in the cppu innards, which might be quite fun. But first
(I suppose) - profiling, I can believe this helps to generate big, slow
code, but it'd be nice to measure that first.

	Thanks,

		Michael.

[1] -
export OOO_DISABLE_RECOVERY=1
valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes ./soffice.bin -writer -splash-pipe=0 /tmp/foo.odt
kcachegrind callgrind*
-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot