Re: Performance test comparisons

Jürgen Schmidt Wed, 13 Feb 2013 03:23:04 -0800

On 2/13/13 12:12 PM, janI wrote:
> 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 ?


you are correct, en-US is the fall back if a string is not localized


> 
>>
>> 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
> 

ok, you have looked deeper than I, really strange. But we don't do that
for all file types containing translations. Maybe only for resource file
which is of course bad enough.


> 
>>
>> 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.

ok I will be quite and let you continue ;-)

Juergen

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

Re: Performance test comparisons

Reply via email to