Re: Performance test comparisons

[janI]

On 13 February 2013 10:33, Jürgen Schmidt <jogischm...@gmail.com> wrote:

> On 2/13/13 9:42 AM, janI wrote:
> > On 13 February 2013 00:47, Andrew Douglas Pitonyak <and...@pitonyak.org
> >wrote:
> >
> >>
> >> If you have a good setup for testing such things, try loading, saving,
> and
> >> closing AndrewMacro.odt
> >>
> >> LO claims that much of their improvements are related to large Calc
> >> documents. Might be nice to find and test their large test Calc
> document...
> >> Not sure what they used, however.
> >>
> >>
> >> On 02/12/2013 07:42 AM, Rob Weir wrote:
> >>
> >>> I did some tests to see how we were doing, comparing AOO 3.4.1 on
> >>> Windows against OOo 3.3.0.  And since LibreOffice claims that their
> >>> 4.0 release is much faster and leaner, I tested them as well, to see
> >>> if we could learn anything.
> >>>
> >>> I just did a basic test, seeing how long it took to load a large text
> >>> document, in this case the ODF 1.2 specification.  I looked at memory
> >>> consumed and the number of seconds to load.  I loaded the document
> >>> once to reduce the impact of disk caching and then repeated 5 times
> >>> and took the average.  All tests done on identical hardware.
> >>>
> >>> Memory use (KB for soffice.bin):
> >>>
> >>> OOo 3.3.0:    133,472
> >>> AOO 3.4.1:   129,928
> >>> LO 4.0:         165,796
> >>>
> >>> Load time for ODF 1.2 specification (seconds, average of 5 loads)
> >>>
> >>> OOo 3.3.0:    16.0
> >>> AOO 3.4.1:    20.9
> >>> LO 4.0:          23.7
> >>>
> >>>
> >>> Does anyone have any other good test documents for doing performance
> >>> tests of OpenOffice?
> >>>
> >>> Regards,
> >>>
> >>> -Rob
> >>>
> >>>
> >> --
> >> Andrew Pitonyak
> >> My Macro Document: http://www.pitonyak.org/**AndrewMacro.odt<
> http://www.pitonyak.org/AndrewMacro.odt>
> >> Info:  http://www.pitonyak.org/oo.php
> >>
> >>
> > Hi.
> >
> > If performance and memory footprint is a concern, we loose a lot in our
> > international version,
> >
> > An average set of language text takes up 1.3Mb in the code segment.
> >
> > Since we release 8 languages, it would be expected to use about 10Mb
> >
> > However, due to the way localize_sl works, we actually include all 116
> > languages from extras/l10n. Meaining the footprint is about 150Mb.
> >
> > I am sure this difference affect, download time, start up time as well as
> > running swap space (on ubuntu 12.04. And at the same time it is something
> > that a simple if could correct (dont  use all languages, but simply
> > --with-lang)
> >
> > Ps. due to the fact that it is scattered in small pieces  over the code,
> > and at least one language is in use, it will effectively also be in main
> > memory.
> >
> > My conclusion is that neither AOO nor LO, is only partial optimized for
> > performance, especially in regard to footprint.
>
> oh, wait wait wait, that is not true. We include one language per
> install set only. I don't say that our packaging is optimal and it would
> be much nicer to have a more flexible mechanism.
>
Actually, we include 2, en-US and the foreign language ?

>
> One reason for the current install set is the one-click user experience
> that is somewhat important for our millions of Windows users ->
> download, click, install... No second download and second click to
> install a lang pack.
>
> You can try to build a multi-lingual install set in instset-native/util
>
> dmake openoffice_en-US_de_da_sv_pl_...
>
> and can compare the size with the simple install sets for one language
> only.
>

Well I dont follow you, I use --with-lang="en da de" and it works
correctly, but the source is actually expanded like this:

StringArray RID_PRINTDLG_STRLIST
{
    ItemList [en-US] =
    {
        < "Print range"; >;
        < "All ~Pages"; >;
        < "Pa~ges"; >;
    };
ItemList [ ar ] =
    {
         < "نطاق الطباعة"; > ;
        < "جميع ~الصفحات"; > ;
        < "الص~فحات"; > ;
    };
    ItemList [ ast ] =
    {
         < "Rangu d'imprentación"; > ;
        < "Toles ~páxines"; > ;
        < "Pá~xines"; > ;
    };
    ItemList [ be-BY ] =
    {
         < "Абсяг друкавання"; > ;
        < "Усе старонкі"; > ;
        < "Друкаваць усе старонкі з
друкавальным зместам."; > ;
    };
    ItemList [ bg ] =
    {
         < "Област за печат"; > ;
        < "Всички ~страници"; > ;
        < "Стра~ници"; > ;
    };
    ItemList [ bs ] =
    {
         < "Opseg za Å¡tampanje"; > ;
        < "Sve ~stranice"; > ;
        < "~Stranice"; > ;
    };
    ItemList [ ca ] =
    {
         < "Àrea d'impressió"; > ;
        < "Totes les ~pà gines"; > ;
        < "PÃ ~gines"; > ;
    };
    ItemList [ ca-XV ] =
    {
         < "Àrea d'impressió"; > ;
        < "Totes les ~pà gines"; > ;
        < "PÃ ~gines"; > ;
    };
    ItemList [ cs ] =
    {
         < "Tisk oblasti"; > ;
        < "Všechny stránky"; > ;
        < "Stránky"; > ;
    };
    ItemList [ cy ] =

Localize_sl, merged all languages into the source, independent of what you
write in --with-lang

I have also controlled the final exe, with "strings", and it do contain
more languages than you selected in --with-lang


>
> The build process and the localization process is far from good or
> optimal but it is not directly related to the outcome (install sets).
> It's more the wasted time during the build process. And the complex and
> not really easy to maintain localization process at all.
>
> From that point I appreciate your work and investigation to improve this
> process. If we can improve in the end the memory footprint in an
> installed office it's even better but I don't see this at the moment.
> Please show me that I am wrong and make it smaller ;-)
>

Actually I did the experiment, I removed some languages in
extras/l10n/source and modified the scripts.

As a consequence (of course) the strings was not found in the install set.

I will not change the running localize_sl, but see to it that genLang works
a bit better.

rgds
Jan I


>
> Juergen
>
>
> >
> > just my 2ct.
> >
> > rgds
> > jan I
> >
>
>