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

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