Re: OK to merge the fw? libraries in framework?

Hi Michael,

Am 09.02.2012 11:32, schrieb Michael Meeks:
>       IMHO the split of GUI code from non-GUI code here would be quite
> reasonable if we had a consumer for that. It seems to me that all
> headless uses of the code-base end up linking VCL and re-using chunks of
> the toolkit anyway though so ... perhaps this was a step to a goal that
> was not reached ?

This was done for two goals - and both of them were never met (because
we were so rudely interrupted ;-)).

One was to remove the "kraken" vcl from as much code as possible because
it seems impossible to get a good architecture as long as vcl has its
many arms everywhere.

The other one stemmed from times where we had the illusion to create a
new toolkit - and having code separated from vcl by toolkit APIs seemed
to be a good idea to contribute to that goal as long as a new toolkit
hadn't shown up.

Those were the days...

> > Besides that, I think that the performance gain by merging libraries is
> > highly overestimated and I doubt that it is worth the penalties you pay
> > for it (larger build times, eroding structures). I know that you have a
> > different opinion about that, but IMHO the time and effort could better
> > be invested into more componentization and keeping unnecessary code from
> > being loaded at startup time.
>
>       This is one of those multi-factor problems that changes with time of
> course. The Mozilla guys - who have put a ton of time into startup
> optimisation on both large devices, and also tiny handheld devices, and
> whom, we interact with quite a bit (they're further ahead in finding the
> pot-holes) merge virtually the whole browser into one shared library -
> to save cold-start seek overhead on load, and of course linking overhead
> on link. Also, if we really want to get good link-time optimisation
> behaviour the more code that the linker can see, and better hide inside
> one big library - the more we win.

On Windows the situation is different. We boosted performance by ca.20%
in OOo 3.2 by preventing paged loading. Of course you can switch on
paging again, but then you first have to catch up with the 20% win from
OOo 3.2 before you can actually gain something.

Or you count on Windows 7 that has such a great super prefetch mechanism
that apps start fast anyway, no matter how you organize your libraries.
That would make any attempts to speed up LO on Windows by working on
library content moot. OTOH it allows you to concentrate on the other
platforms and leave Windows out of the picture. Windows 7 already takes
50% of the Windows market, IIRC.

>       Worse than that, for the iPhone, I believe we are doomed to needing a
> single-monster statically linked blob :-) which sounds even more
> interesting, we've done some chunks of work to move there
> (dis-ambiguating the component_ symbols eg.).

I think that the biggest problem for LO on iOS will be something
completely different: the review by Apple that needs to be passed -
unless you are fine with not getting into the App Store and just running
on jailbreaked devices. ;-)

Another big technical problem is that on mobile devices apps can be
killed at anytime at the will of the operating system. Apps need to be
designed to live under these circumstances.

> http://www.techradar.com/reviews/pc-mac/tablets/asus-eee-pad-transformer-954145/review
>
>       And have dual-core GHz ARM CPUs (or even beefy Intel CPUs). That can
> make it hard to conceptually separate the segment from a 'netbook'. Of
> course, LibreOffice on a phone form-factor in it's current state is
> unrealistic.

Indeed, these devives will fit better. Nevertheless as a user I would
prefer smaller apps even of such machines. YMMV - and hopefully the
mileage of many other people also.

It will be interesting to follow how LO with its desktop based
application paradigm (documents, windows, dialogs etc.) will fit into
the Android world of activities, components, services etc. I will be
watching. :-)

Best regards,
Mathias