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.me...@novell.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
