On 13 February 2013 12:22, Jürgen Schmidt <jogischm...@gmail.com> wrote:
> 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. > You might be right there, I have only looked at .src files at the moment. I am still testing that genLang produces 100% the same output as localize_sl, and merge it back in the same way. Btw: I have also found several strings in the sources where [en-US] is missing, meaning neither genLang or locallize_sl extract them, I will correct that later. > > > > > >> > >> 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 ;-) > No no, your input is highly valued.....you correct my misunderstanding more often, which I like, since it saves me time :-) > > Juergen > > > > > rgds > > Jan I > > > > > >> > >> Juergen > >> > >> > >>> > >>> just my 2ct. > >>> > >>> rgds > >>> jan I > >>> > >> > >> > > > >
