On 21.06.2011 13:40, Andrea Pescetti wrote:
Simon Phipps wrote:
Certainly the code cleanup performed by the LibreOffice developers
over the last 9 months has had a huge impact, both in terms of code
footprint and performance.
Can you provide any supporting data? Having some "canonical" metrics
would also help in evaluating the future code rewrite that will have to
be done at Apache.
Not to diminish at all the work done by the LibreOffice developers, but
as far as I know the largest code cleanup changes (criteria: number of
developers involved, number of modified lines) made in LibreOffice
concerned translation of comments and removal of dead ("#if 0") code,
and this cannot affect footprint or performance.
I saw published stats about how the icon deduplication will reduce
footprint in future releases (and, to a lesser extent, in current
releases) of LibreOffice, but nothing significant on performance. Could
you share some data on it, and especially some metrics that can be
retested with the future Apache code to assess its performance
improvements? Thanks!
Just because you asked, caused by Simon's non-developer view of things:
If have checked the latest versions (3.3 and 3.4 Beta) of LO and OOo. I
tested warm start and document load/save performance of Writer, and the
differences on Windows and Ubuntu Linux are negligible. (The usual kind
of test: boot machine, do a cold start of the application, then
calculate the average time of 5 "warm" runs).
But the current work they do with library rearrangement looks
interesting. Merging libraries (or even better: completely rearranging
their content based on its relevance for the startup) should improve
startup performance. We (the OOo framework team) had planned to work on
that also. A lot of refactoring work in the last 2 years was done in
preparation for that.
So indeed nothing the LO developers have done has observably improved
the overall performance. The great thing the LO developers did is the
code cleanup. It doesn't make the application faster, but handling and
understanding the code is improved. Perhaps it also helps with the
library rearrangement.
Anyway, let's talk about OOo now.
Regards,
Mathias
