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 _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
