You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by imacat <im...@mail.imacat.idv.tw> on 2012/05/10 11:25:05 UTC
Fwd: Performance!
FYI ^_*'
Please do not attack any party, or create any FUD.
------- Original mail -------
Subject: Performance!
Date: Wed, 09 May 2012 23:51:47 +0200
From: Armin Le Grand <ar...@me.com>
Nice read: http://tinyurl.com/c24awgq
--
ALG (iPad)
--
Best regards,
imacat ^_*' <im...@mail.imacat.idv.tw>
PGP Key http://www.imacat.idv.tw/me/pgpkey.asc
<<Woman's Voice>> News: http://www.wov.idv.tw/
Tavern IMACAT's http://www.imacat.idv.tw/
Woman in FOSS in Taiwan http://wofoss.blogspot.com/
Apache OpenOffice http://www.openoffice.org/
EducOO/OOo4Kids Taiwan http://www.educoo.tw/
RE: Performance!
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I have no problem with users having whatever performance experiences they have. However, it is no basis for *us* who have technical responsibilities here to presume that is usable as a technical fact.
It is like saying 9 out of 12 users perceive improved performance of Apache OpenOffice 3.4.0. So what? Automobile gasoline mileage ratings are better than that and remember, YMMV!!
It is meaningless and we should not be so anxious to rely on hearsay.
What's needed is dependable, repeatable statistics gathered under controlled conditions. The information should be available for the purpose of our technical assessment of areas for improvement, of places where feature attempts add degradation, etc.
- Dennis
-----Original Message-----
From: Andre Fischer [mailto:af@a-w-f.de]
Sent: Friday, May 11, 2012 00:27
To: ooo-dev@incubator.apache.org
Subject: Re: Performance!
On 10.05.2012 18:23, Dennis E. Hamilton wrote:
> All right, this seems like a good place to splice in a comment I made in the private thread that it is time to be careful and not get into exaggerated claims, especially when a variation is not consistently present to all users in all situations.
>
> Unsubstantiated subjective experiences are not trustworthy.
That is true. But OpenOffice is not a high performance computing
application. When a user thinks that it is fast enough then it IS fast
enough.
-Andre
> It is also very difficult to control the variations that exist from one setting and execution to another.
>
> So let's stop making so much of this.
>
> - Dennis
>
> A LESSON ON PERFORMANCE-CLAIM HUMILITY:
>
> I just stubbed my toe on a performance situation where there is a serious worse-than-linear degradation in performance as a particular kind of ODF Text document grows. Using a hot machine, I only noticed the pain when opening the document extended into an intolerable number of minutes as I continued work on successive drafts. On my slower laptop, where I repeated the test for comparison purpose, the document now takes over an hour to open. This is on OO.o 3.3.0, AOO 3.4.0, and a variety of LibreOffice releases.
>
> Yes there are differences among the different releases, and they are rather consistent when the time is so long, but the fastest (OpenOffice.org 3.3.0 in my crude tests) is still swamped by whatever the serious performance degradation is and it is common to all releases tested.
>
> This is not the kind of problem that can be isolated into a small test case for reproducibility, so the forensic work to demonstrate it and capture data points is really tedious. Ordinary users probably think that their software has hung or is not even starting when it is just that there is something that is taking a very long time as part of loading the document (but neither disk nor network, something in the logic that pegs the CPU for minutes when not hours).
>
> Bug reports will follow shortly.
>
> -----Original Message-----
> From: Jürgen Schmidt [mailto:jogischmidt@googlemail.com]
> Sent: Thursday, May 10, 2012 08:45
> To: ooo-dev@incubator.apache.org
> Subject: Re: Performance!
>
> [ ... ]
>
> But the point right now is that the majority of users don't care about
> this and see only that AOO is starting fast. A fact that I like very
> much because there were indeed some improvements for 3.4.
>
> And how nice is it when users notice such improvements without deeper
> analysis. The fact that users simply having the impression that it
> starts fast is very nice.
>
> So let us focus on further improvement going in this direction. Let us
> make our users happy. Many many happy users and their positive feedback
> is the payment that we get for our work here.
>
> Juergen
>
> [ ... ]
>
Re: Performance!
Posted by Andre Fischer <af...@a-w-f.de>.
On 10.05.2012 18:23, Dennis E. Hamilton wrote:
> All right, this seems like a good place to splice in a comment I made in the private thread that it is time to be careful and not get into exaggerated claims, especially when a variation is not consistently present to all users in all situations.
>
> Unsubstantiated subjective experiences are not trustworthy.
That is true. But OpenOffice is not a high performance computing
application. When a user thinks that it is fast enough then it IS fast
enough.
-Andre
> It is also very difficult to control the variations that exist from one setting and execution to another.
>
> So let's stop making so much of this.
>
> - Dennis
>
> A LESSON ON PERFORMANCE-CLAIM HUMILITY:
>
> I just stubbed my toe on a performance situation where there is a serious worse-than-linear degradation in performance as a particular kind of ODF Text document grows. Using a hot machine, I only noticed the pain when opening the document extended into an intolerable number of minutes as I continued work on successive drafts. On my slower laptop, where I repeated the test for comparison purpose, the document now takes over an hour to open. This is on OO.o 3.3.0, AOO 3.4.0, and a variety of LibreOffice releases.
>
> Yes there are differences among the different releases, and they are rather consistent when the time is so long, but the fastest (OpenOffice.org 3.3.0 in my crude tests) is still swamped by whatever the serious performance degradation is and it is common to all releases tested.
>
> This is not the kind of problem that can be isolated into a small test case for reproducibility, so the forensic work to demonstrate it and capture data points is really tedious. Ordinary users probably think that their software has hung or is not even starting when it is just that there is something that is taking a very long time as part of loading the document (but neither disk nor network, something in the logic that pegs the CPU for minutes when not hours).
>
> Bug reports will follow shortly.
>
> -----Original Message-----
> From: Jürgen Schmidt [mailto:jogischmidt@googlemail.com]
> Sent: Thursday, May 10, 2012 08:45
> To: ooo-dev@incubator.apache.org
> Subject: Re: Performance!
>
> [ ... ]
>
> But the point right now is that the majority of users don't care about
> this and see only that AOO is starting fast. A fact that I like very
> much because there were indeed some improvements for 3.4.
>
> And how nice is it when users notice such improvements without deeper
> analysis. The fact that users simply having the impression that it
> starts fast is very nice.
>
> So let us focus on further improvement going in this direction. Let us
> make our users happy. Many many happy users and their positive feedback
> is the payment that we get for our work here.
>
> Juergen
>
> [ ... ]
>
RE: Performance!
Posted by "Dennis E. Hamilton" <de...@acm.org>.
@Juergen,
Here you go:
<https://issues.apache.org/ooo/show_bug.cgi?id=119341>.
-----Original Message-----
From: Juergen Schmidt [mailto:jogischmidt@googlemail.com]
Sent: Thursday, May 10, 2012 14:02
To: ooo-dev@incubator.apache.org; dennis.hamilton@acm.org
Subject: Re: Performance!
On Thursday, 10. May 2012 at 18:23, Dennis E. Hamilton wrote:
> All right, this seems like a good place to splice in a comment I made in the private thread that it is time to be careful and not get into exaggerated claims, especially when a variation is not consistently present to all users in all situations.
>
> Unsubstantiated subjective experiences are not trustworthy. It is also very difficult to control the variations that exist from one setting and execution to another.
>
> So let's stop making so much of this.
ah thanks Dennis that you didn't get my point but probably my fault that I didn't get or find the correct words.
I think it is easy to find documents where the performance is not really good. And we are looking forward to your reports, your test docs and especially your fixes and improvements.
[ ... ]
Re: Performance!
Posted by Juergen Schmidt <jo...@googlemail.com>.
On Thursday, 10. May 2012 at 18:23, Dennis E. Hamilton wrote:
> All right, this seems like a good place to splice in a comment I made in the private thread that it is time to be careful and not get into exaggerated claims, especially when a variation is not consistently present to all users in all situations.
>
> Unsubstantiated subjective experiences are not trustworthy. It is also very difficult to control the variations that exist from one setting and execution to another.
>
> So let's stop making so much of this.
ah thanks Dennis that you didn't get my point but probably my fault that I didn't get or find the correct words.
I think it is easy to find documents where the performance is not really good. And we are looking forward to your reports, your test docs and especially your fixes and improvements.
My point was that many users will work with much simpler documents, they will get the impression (and not only the impression) that 3.4 is faster...
And that is good, simply good and you see it from the feedback.
We have achieved a very important milestone this week. I am personally still enjoy it and I like what I read every day
at the moment. Well I don't read everything ;-)
And I really don't want compete with LibreOffice, why should we? I really see no reason for this. I see only that split resources on 2 similar projects don't really make sense but I can't change it at the moment. I focus on our project and everything else we will see...
Juergen
>
> - Dennis
>
> A LESSON ON PERFORMANCE-CLAIM HUMILITY:
>
> I just stubbed my toe on a performance situation where there is a serious worse-than-linear degradation in performance as a particular kind of ODF Text document grows. Using a hot machine, I only noticed the pain when opening the document extended into an intolerable number of minutes as I continued work on successive drafts. On my slower laptop, where I repeated the test for comparison purpose, the document now takes over an hour to open. This is on OO.o 3.3.0, AOO 3.4.0, and a variety of LibreOffice releases.
>
> Yes there are differences among the different releases, and they are rather consistent when the time is so long, but the fastest (OpenOffice.org 3.3.0 in my crude tests) is still swamped by whatever the serious performance degradation is and it is common to all releases tested.
>
> This is not the kind of problem that can be isolated into a small test case for reproducibility, so the forensic work to demonstrate it and capture data points is really tedious. Ordinary users probably think that their software has hung or is not even starting when it is just that there is something that is taking a very long time as part of loading the document (but neither disk nor network, something in the logic that pegs the CPU for minutes when not hours).
>
> Bug reports will follow shortly.
>
> -----Original Message-----
> From: Jürgen Schmidt [mailto:jogischmidt@googlemail.com]
> Sent: Thursday, May 10, 2012 08:45
> To: ooo-dev@incubator.apache.org
> Subject: Re: Performance!
>
> [ ... ]
>
> But the point right now is that the majority of users don't care about
> this and see only that AOO is starting fast. A fact that I like very
> much because there were indeed some improvements for 3.4.
>
> And how nice is it when users notice such improvements without deeper
> analysis. The fact that users simply having the impression that it
> starts fast is very nice.
>
> So let us focus on further improvement going in this direction. Let us
> make our users happy. Many many happy users and their positive feedback
> is the payment that we get for our work here.
>
> Juergen
>
> [ ... ]
RE: Performance!
Posted by "Dennis E. Hamilton" <de...@acm.org>.
All right, this seems like a good place to splice in a comment I made in the private thread that it is time to be careful and not get into exaggerated claims, especially when a variation is not consistently present to all users in all situations.
Unsubstantiated subjective experiences are not trustworthy. It is also very difficult to control the variations that exist from one setting and execution to another.
So let's stop making so much of this.
- Dennis
A LESSON ON PERFORMANCE-CLAIM HUMILITY:
I just stubbed my toe on a performance situation where there is a serious worse-than-linear degradation in performance as a particular kind of ODF Text document grows. Using a hot machine, I only noticed the pain when opening the document extended into an intolerable number of minutes as I continued work on successive drafts. On my slower laptop, where I repeated the test for comparison purpose, the document now takes over an hour to open. This is on OO.o 3.3.0, AOO 3.4.0, and a variety of LibreOffice releases.
Yes there are differences among the different releases, and they are rather consistent when the time is so long, but the fastest (OpenOffice.org 3.3.0 in my crude tests) is still swamped by whatever the serious performance degradation is and it is common to all releases tested.
This is not the kind of problem that can be isolated into a small test case for reproducibility, so the forensic work to demonstrate it and capture data points is really tedious. Ordinary users probably think that their software has hung or is not even starting when it is just that there is something that is taking a very long time as part of loading the document (but neither disk nor network, something in the logic that pegs the CPU for minutes when not hours).
Bug reports will follow shortly.
-----Original Message-----
From: Jürgen Schmidt [mailto:jogischmidt@googlemail.com]
Sent: Thursday, May 10, 2012 08:45
To: ooo-dev@incubator.apache.org
Subject: Re: Performance!
[ ... ]
But the point right now is that the majority of users don't care about
this and see only that AOO is starting fast. A fact that I like very
much because there were indeed some improvements for 3.4.
And how nice is it when users notice such improvements without deeper
analysis. The fact that users simply having the impression that it
starts fast is very nice.
So let us focus on further improvement going in this direction. Let us
make our users happy. Many many happy users and their positive feedback
is the payment that we get for our work here.
Juergen
[ ... ]
Re: Performance!
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 5/10/12 5:30 PM, drew wrote:
> On Thu, 2012-05-10 at 17:23 +0200, Andre Fischer wrote:
>> On 10.05.2012 17:06, drew wrote:
>>> On Thu, 2012-05-10 at 08:51 -0400, Rob Weir wrote:
>>>> On Thu, May 10, 2012 at 8:10 AM, Rob Weir<ro...@apache.org> wrote:
>>>>> On Thu, May 10, 2012 at 6:53 AM, Ross Gardler
>>>>> <rg...@opendirective.com> wrote:
>>>>>> Thanks Imacat,
>>>>>>
>>>>>> This was originally posted to the private list so as not to offend
>>>>>> some of our more sensitive list subscribers. However, some useful
>>>>>> discussion started looking at why the graphs looked like they did. I,
>>>>>> as a mentor, requested that it be moved here so that everyone, could
>>>>>> benefit from the discussion. Imacat did not post all comments, only
>>>>>> the link that was the catalyst, since they were made in private, it's
>>>>>> up to others to bring their constructive thoughts here.
>>>>>>
>>>>>> I think I see a potential for collaboration between the various ODF
>>>>>> related projects here.
>>>>>>
>>>>>> Can a few sample documents be created which produce graphs showing
>>>>>> better performance in other ODF products? Michael, you say they can do
>>>>>> that for LO, I invite you to do so. Such documents would help AOO
>>>>>> developers explore weakness in AOO code.
>>>>>>
>>>>>> At the same time AOO could provide documents that demonstrate better
>>>>>> AOO performance. These will help other projects explore weaknesses in
>>>>>> their own code.
>>>>>>
>>>>>> RANDOM THOUGHT: are there any ODF test documents that might serve this purpose?
>>>>>>
>>>>> Another idea: the blog post also indicates that AOO 3.4 uses less RAM
>>>>> than LO: 35Mb versus 43MB. This might be related to the start up
>>>>> performance difference. But since neither product has made radical
>>>>> changes to internal memory structures, any difference in memory
>>>>> consumption is probably related to what libraries are loaded at
>>>>> startup. That should be easier to track down.
>>>>>
>>>>> Also, a comparison of AOO 3.4 versus OOo 3.3.0 would indicate whether
>>>>> we're dealing with a coding improvement in AOO 3.4 or a regression in
>>>>> LO. Whatever the result, that gives useful information that can be
>>>>> used to improve performance.
>>>>>
>>>> A quick test suggests a little of both:
>>>>
>>>> Looking soffice.bin ("working set" memory footprint in Windows XP) for
>>>> Writer start up, no document loaded:
>>>>
>>>> OOo 3.3.0 = 95,792 Kb
>>>> AOO 3.4.0 = 88,508 Kb
>>>> LO 3.5.1 = 108,120 Kb
>>>>
>>>> So compared to OOo 3.3.0, AOO 3.4 is reduced 8% and LO increased 13%.
>>>> Of course, RAM is (relatively) cheap, so the raw numbers are not that
>>>> important. But any associated initialization code associated with
>>>> whatever is causing this difference, that could easily impact start
>>>> performance.
>>>>
>>> Alright - likely I don't need to ask this - The packages ship from a
>>> really different mindset, one Aoo is bare bones (particularly this
>>> specific release) and LibO comes with condiments.
>>
>> I don´t know about bare bones. Sure, we removed a small number of
>> libraries, but AOO 3.4 is still a regular release when it comes to
>> functionality.
>>
>>>
>>> So - just to be sure, did you pull out the extras (the extensions) that
>>> come default with LibO, before checking the footprint?
>>
>> Extensions are loaded on demand. Even if Libre Office includes more
>> extensions and may even have turned some extensions into "regular" code,
>> that does not change the size of soffice.bin.
>
> I think it does - I just did that, though I'm under Linux currently, so
> perhaps that's a difference - anyway - added extensions to both Aoo and
> Libo and the footprint for soffice.bin changed in each, for subsequent
> loads.
it depends indeed on the extension. The loading on demand conclusion is
of course correct but depends on the service provider interface (SPI)
that is used.
But the point right now is that the majority of users don't care about
this and see only that AOO is starting fast. A fact that I like very
much because there were indeed some improvements for 3.4.
And how nice is it when users notice such improvements without deeper
analysis. The fact that users simply having the impression that it
starts fast is very nice.
So let us focus on further improvement going in this direction. Let us
make our users happy. Many many happy users and their positive feedback
is the payment that we get for our work here.
Juergen
>
> //drew
>
>>
>> -Andre
>>
>>
>
>
Re: Performance!
Posted by drew <dr...@baseanswers.com>.
On Thu, 2012-05-10 at 17:23 +0200, Andre Fischer wrote:
> On 10.05.2012 17:06, drew wrote:
> > On Thu, 2012-05-10 at 08:51 -0400, Rob Weir wrote:
> >> On Thu, May 10, 2012 at 8:10 AM, Rob Weir<ro...@apache.org> wrote:
> >>> On Thu, May 10, 2012 at 6:53 AM, Ross Gardler
> >>> <rg...@opendirective.com> wrote:
> >>>> Thanks Imacat,
> >>>>
> >>>> This was originally posted to the private list so as not to offend
> >>>> some of our more sensitive list subscribers. However, some useful
> >>>> discussion started looking at why the graphs looked like they did. I,
> >>>> as a mentor, requested that it be moved here so that everyone, could
> >>>> benefit from the discussion. Imacat did not post all comments, only
> >>>> the link that was the catalyst, since they were made in private, it's
> >>>> up to others to bring their constructive thoughts here.
> >>>>
> >>>> I think I see a potential for collaboration between the various ODF
> >>>> related projects here.
> >>>>
> >>>> Can a few sample documents be created which produce graphs showing
> >>>> better performance in other ODF products? Michael, you say they can do
> >>>> that for LO, I invite you to do so. Such documents would help AOO
> >>>> developers explore weakness in AOO code.
> >>>>
> >>>> At the same time AOO could provide documents that demonstrate better
> >>>> AOO performance. These will help other projects explore weaknesses in
> >>>> their own code.
> >>>>
> >>>> RANDOM THOUGHT: are there any ODF test documents that might serve this purpose?
> >>>>
> >>> Another idea: the blog post also indicates that AOO 3.4 uses less RAM
> >>> than LO: 35Mb versus 43MB. This might be related to the start up
> >>> performance difference. But since neither product has made radical
> >>> changes to internal memory structures, any difference in memory
> >>> consumption is probably related to what libraries are loaded at
> >>> startup. That should be easier to track down.
> >>>
> >>> Also, a comparison of AOO 3.4 versus OOo 3.3.0 would indicate whether
> >>> we're dealing with a coding improvement in AOO 3.4 or a regression in
> >>> LO. Whatever the result, that gives useful information that can be
> >>> used to improve performance.
> >>>
> >> A quick test suggests a little of both:
> >>
> >> Looking soffice.bin ("working set" memory footprint in Windows XP) for
> >> Writer start up, no document loaded:
> >>
> >> OOo 3.3.0 = 95,792 Kb
> >> AOO 3.4.0 = 88,508 Kb
> >> LO 3.5.1 = 108,120 Kb
> >>
> >> So compared to OOo 3.3.0, AOO 3.4 is reduced 8% and LO increased 13%.
> >> Of course, RAM is (relatively) cheap, so the raw numbers are not that
> >> important. But any associated initialization code associated with
> >> whatever is causing this difference, that could easily impact start
> >> performance.
> >>
> > Alright - likely I don't need to ask this - The packages ship from a
> > really different mindset, one Aoo is bare bones (particularly this
> > specific release) and LibO comes with condiments.
>
> I don´t know about bare bones. Sure, we removed a small number of
> libraries, but AOO 3.4 is still a regular release when it comes to
> functionality.
>
> >
> > So - just to be sure, did you pull out the extras (the extensions) that
> > come default with LibO, before checking the footprint?
>
> Extensions are loaded on demand. Even if Libre Office includes more
> extensions and may even have turned some extensions into "regular" code,
> that does not change the size of soffice.bin.
I think it does - I just did that, though I'm under Linux currently, so
perhaps that's a difference - anyway - added extensions to both Aoo and
Libo and the footprint for soffice.bin changed in each, for subsequent
loads.
//drew
>
> -Andre
>
>
Re: Performance!
Posted by Andre Fischer <af...@a-w-f.de>.
On 10.05.2012 17:06, drew wrote:
> On Thu, 2012-05-10 at 08:51 -0400, Rob Weir wrote:
>> On Thu, May 10, 2012 at 8:10 AM, Rob Weir<ro...@apache.org> wrote:
>>> On Thu, May 10, 2012 at 6:53 AM, Ross Gardler
>>> <rg...@opendirective.com> wrote:
>>>> Thanks Imacat,
>>>>
>>>> This was originally posted to the private list so as not to offend
>>>> some of our more sensitive list subscribers. However, some useful
>>>> discussion started looking at why the graphs looked like they did. I,
>>>> as a mentor, requested that it be moved here so that everyone, could
>>>> benefit from the discussion. Imacat did not post all comments, only
>>>> the link that was the catalyst, since they were made in private, it's
>>>> up to others to bring their constructive thoughts here.
>>>>
>>>> I think I see a potential for collaboration between the various ODF
>>>> related projects here.
>>>>
>>>> Can a few sample documents be created which produce graphs showing
>>>> better performance in other ODF products? Michael, you say they can do
>>>> that for LO, I invite you to do so. Such documents would help AOO
>>>> developers explore weakness in AOO code.
>>>>
>>>> At the same time AOO could provide documents that demonstrate better
>>>> AOO performance. These will help other projects explore weaknesses in
>>>> their own code.
>>>>
>>>> RANDOM THOUGHT: are there any ODF test documents that might serve this purpose?
>>>>
>>> Another idea: the blog post also indicates that AOO 3.4 uses less RAM
>>> than LO: 35Mb versus 43MB. This might be related to the start up
>>> performance difference. But since neither product has made radical
>>> changes to internal memory structures, any difference in memory
>>> consumption is probably related to what libraries are loaded at
>>> startup. That should be easier to track down.
>>>
>>> Also, a comparison of AOO 3.4 versus OOo 3.3.0 would indicate whether
>>> we're dealing with a coding improvement in AOO 3.4 or a regression in
>>> LO. Whatever the result, that gives useful information that can be
>>> used to improve performance.
>>>
>> A quick test suggests a little of both:
>>
>> Looking soffice.bin ("working set" memory footprint in Windows XP) for
>> Writer start up, no document loaded:
>>
>> OOo 3.3.0 = 95,792 Kb
>> AOO 3.4.0 = 88,508 Kb
>> LO 3.5.1 = 108,120 Kb
>>
>> So compared to OOo 3.3.0, AOO 3.4 is reduced 8% and LO increased 13%.
>> Of course, RAM is (relatively) cheap, so the raw numbers are not that
>> important. But any associated initialization code associated with
>> whatever is causing this difference, that could easily impact start
>> performance.
>>
> Alright - likely I don't need to ask this - The packages ship from a
> really different mindset, one Aoo is bare bones (particularly this
> specific release) and LibO comes with condiments.
I don´t know about bare bones. Sure, we removed a small number of
libraries, but AOO 3.4 is still a regular release when it comes to
functionality.
>
> So - just to be sure, did you pull out the extras (the extensions) that
> come default with LibO, before checking the footprint?
Extensions are loaded on demand. Even if Libre Office includes more
extensions and may even have turned some extensions into "regular" code,
that does not change the size of soffice.bin.
-Andre
Re: Performance!
Posted by drew <dr...@baseanswers.com>.
On Thu, 2012-05-10 at 11:31 -0400, Rob Weir wrote:
> On Thu, May 10, 2012 at 11:06 AM, drew <dr...@baseanswers.com> wrote:
> > On Thu, 2012-05-10 at 08:51 -0400, Rob Weir wrote:
> >> On Thu, May 10, 2012 at 8:10 AM, Rob Weir <ro...@apache.org> wrote:
> >> > On Thu, May 10, 2012 at 6:53 AM, Ross Gardler
> >> > <rg...@opendirective.com> wrote:
> >> >> Thanks Imacat,
> >> >>
> >> >> This was originally posted to the private list so as not to offend
> >> >> some of our more sensitive list subscribers. However, some useful
> >> >> discussion started looking at why the graphs looked like they did. I,
> >> >> as a mentor, requested that it be moved here so that everyone, could
> >> >> benefit from the discussion. Imacat did not post all comments, only
> >> >> the link that was the catalyst, since they were made in private, it's
> >> >> up to others to bring their constructive thoughts here.
> >> >>
> >> >> I think I see a potential for collaboration between the various ODF
> >> >> related projects here.
> >> >>
> >> >> Can a few sample documents be created which produce graphs showing
> >> >> better performance in other ODF products? Michael, you say they can do
> >> >> that for LO, I invite you to do so. Such documents would help AOO
> >> >> developers explore weakness in AOO code.
> >> >>
> >> >> At the same time AOO could provide documents that demonstrate better
> >> >> AOO performance. These will help other projects explore weaknesses in
> >> >> their own code.
> >> >>
> >> >> RANDOM THOUGHT: are there any ODF test documents that might serve this purpose?
> >> >>
> >> >
> >> > Another idea: the blog post also indicates that AOO 3.4 uses less RAM
> >> > than LO: 35Mb versus 43MB. This might be related to the start up
> >> > performance difference. But since neither product has made radical
> >> > changes to internal memory structures, any difference in memory
> >> > consumption is probably related to what libraries are loaded at
> >> > startup. That should be easier to track down.
> >> >
> >> > Also, a comparison of AOO 3.4 versus OOo 3.3.0 would indicate whether
> >> > we're dealing with a coding improvement in AOO 3.4 or a regression in
> >> > LO. Whatever the result, that gives useful information that can be
> >> > used to improve performance.
> >> >
> >>
> >> A quick test suggests a little of both:
> >>
> >> Looking soffice.bin ("working set" memory footprint in Windows XP) for
> >> Writer start up, no document loaded:
> >>
> >> OOo 3.3.0 = 95,792 Kb
> >> AOO 3.4.0 = 88,508 Kb
> >> LO 3.5.1 = 108,120 Kb
> >>
> >> So compared to OOo 3.3.0, AOO 3.4 is reduced 8% and LO increased 13%.
> >> Of course, RAM is (relatively) cheap, so the raw numbers are not that
> >> important. But any associated initialization code associated with
> >> whatever is causing this difference, that could easily impact start
> >> performance.
> >>
> >
> > Alright - likely I don't need to ask this - The packages ship from a
> > really different mindset, one Aoo is bare bones (particularly this
> > specific release) and LibO comes with condiments.
> >
> > So - just to be sure, did you pull out the extras (the extensions) that
> > come default with LibO, before checking the footprint?
> >
>
> Just the default install. I didn't change anything. And likely
> neither did the user who was doing the timings.
>
> If that explains the start up differences and the working set
> differences, then that is good to know. As engineers I think we all
> struggle to find ways to add features without slowing the product
> down. We'll face the same set of issues.as we enhance AOO.
>
> -Rob
Howdy,
Historically there have been some problems with extensions and overall
performance - IIRC - some of the grammar checkers, early on, caused
issues. A little voice says maybe there was an issue logged about
dictionaries also, but not sure on that.
//drew
>
>
> > Thanks,
> >
> > //drew
> >
>
Re: Performance!
Posted by Rob Weir <ro...@apache.org>.
On Thu, May 10, 2012 at 11:06 AM, drew <dr...@baseanswers.com> wrote:
> On Thu, 2012-05-10 at 08:51 -0400, Rob Weir wrote:
>> On Thu, May 10, 2012 at 8:10 AM, Rob Weir <ro...@apache.org> wrote:
>> > On Thu, May 10, 2012 at 6:53 AM, Ross Gardler
>> > <rg...@opendirective.com> wrote:
>> >> Thanks Imacat,
>> >>
>> >> This was originally posted to the private list so as not to offend
>> >> some of our more sensitive list subscribers. However, some useful
>> >> discussion started looking at why the graphs looked like they did. I,
>> >> as a mentor, requested that it be moved here so that everyone, could
>> >> benefit from the discussion. Imacat did not post all comments, only
>> >> the link that was the catalyst, since they were made in private, it's
>> >> up to others to bring their constructive thoughts here.
>> >>
>> >> I think I see a potential for collaboration between the various ODF
>> >> related projects here.
>> >>
>> >> Can a few sample documents be created which produce graphs showing
>> >> better performance in other ODF products? Michael, you say they can do
>> >> that for LO, I invite you to do so. Such documents would help AOO
>> >> developers explore weakness in AOO code.
>> >>
>> >> At the same time AOO could provide documents that demonstrate better
>> >> AOO performance. These will help other projects explore weaknesses in
>> >> their own code.
>> >>
>> >> RANDOM THOUGHT: are there any ODF test documents that might serve this purpose?
>> >>
>> >
>> > Another idea: the blog post also indicates that AOO 3.4 uses less RAM
>> > than LO: 35Mb versus 43MB. This might be related to the start up
>> > performance difference. But since neither product has made radical
>> > changes to internal memory structures, any difference in memory
>> > consumption is probably related to what libraries are loaded at
>> > startup. That should be easier to track down.
>> >
>> > Also, a comparison of AOO 3.4 versus OOo 3.3.0 would indicate whether
>> > we're dealing with a coding improvement in AOO 3.4 or a regression in
>> > LO. Whatever the result, that gives useful information that can be
>> > used to improve performance.
>> >
>>
>> A quick test suggests a little of both:
>>
>> Looking soffice.bin ("working set" memory footprint in Windows XP) for
>> Writer start up, no document loaded:
>>
>> OOo 3.3.0 = 95,792 Kb
>> AOO 3.4.0 = 88,508 Kb
>> LO 3.5.1 = 108,120 Kb
>>
>> So compared to OOo 3.3.0, AOO 3.4 is reduced 8% and LO increased 13%.
>> Of course, RAM is (relatively) cheap, so the raw numbers are not that
>> important. But any associated initialization code associated with
>> whatever is causing this difference, that could easily impact start
>> performance.
>>
>
> Alright - likely I don't need to ask this - The packages ship from a
> really different mindset, one Aoo is bare bones (particularly this
> specific release) and LibO comes with condiments.
>
> So - just to be sure, did you pull out the extras (the extensions) that
> come default with LibO, before checking the footprint?
>
Just the default install. I didn't change anything. And likely
neither did the user who was doing the timings.
If that explains the start up differences and the working set
differences, then that is good to know. As engineers I think we all
struggle to find ways to add features without slowing the product
down. We'll face the same set of issues.as we enhance AOO.
-Rob
> Thanks,
>
> //drew
>
Re: Performance!
Posted by drew <dr...@baseanswers.com>.
On Thu, 2012-05-10 at 08:51 -0400, Rob Weir wrote:
> On Thu, May 10, 2012 at 8:10 AM, Rob Weir <ro...@apache.org> wrote:
> > On Thu, May 10, 2012 at 6:53 AM, Ross Gardler
> > <rg...@opendirective.com> wrote:
> >> Thanks Imacat,
> >>
> >> This was originally posted to the private list so as not to offend
> >> some of our more sensitive list subscribers. However, some useful
> >> discussion started looking at why the graphs looked like they did. I,
> >> as a mentor, requested that it be moved here so that everyone, could
> >> benefit from the discussion. Imacat did not post all comments, only
> >> the link that was the catalyst, since they were made in private, it's
> >> up to others to bring their constructive thoughts here.
> >>
> >> I think I see a potential for collaboration between the various ODF
> >> related projects here.
> >>
> >> Can a few sample documents be created which produce graphs showing
> >> better performance in other ODF products? Michael, you say they can do
> >> that for LO, I invite you to do so. Such documents would help AOO
> >> developers explore weakness in AOO code.
> >>
> >> At the same time AOO could provide documents that demonstrate better
> >> AOO performance. These will help other projects explore weaknesses in
> >> their own code.
> >>
> >> RANDOM THOUGHT: are there any ODF test documents that might serve this purpose?
> >>
> >
> > Another idea: the blog post also indicates that AOO 3.4 uses less RAM
> > than LO: 35Mb versus 43MB. This might be related to the start up
> > performance difference. But since neither product has made radical
> > changes to internal memory structures, any difference in memory
> > consumption is probably related to what libraries are loaded at
> > startup. That should be easier to track down.
> >
> > Also, a comparison of AOO 3.4 versus OOo 3.3.0 would indicate whether
> > we're dealing with a coding improvement in AOO 3.4 or a regression in
> > LO. Whatever the result, that gives useful information that can be
> > used to improve performance.
> >
>
> A quick test suggests a little of both:
>
> Looking soffice.bin ("working set" memory footprint in Windows XP) for
> Writer start up, no document loaded:
>
> OOo 3.3.0 = 95,792 Kb
> AOO 3.4.0 = 88,508 Kb
> LO 3.5.1 = 108,120 Kb
>
> So compared to OOo 3.3.0, AOO 3.4 is reduced 8% and LO increased 13%.
> Of course, RAM is (relatively) cheap, so the raw numbers are not that
> important. But any associated initialization code associated with
> whatever is causing this difference, that could easily impact start
> performance.
>
Alright - likely I don't need to ask this - The packages ship from a
really different mindset, one Aoo is bare bones (particularly this
specific release) and LibO comes with condiments.
So - just to be sure, did you pull out the extras (the extensions) that
come default with LibO, before checking the footprint?
Thanks,
//drew
Re: Performance!
Posted by Rob Weir <ro...@apache.org>.
On Thu, May 10, 2012 at 8:10 AM, Rob Weir <ro...@apache.org> wrote:
> On Thu, May 10, 2012 at 6:53 AM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> Thanks Imacat,
>>
>> This was originally posted to the private list so as not to offend
>> some of our more sensitive list subscribers. However, some useful
>> discussion started looking at why the graphs looked like they did. I,
>> as a mentor, requested that it be moved here so that everyone, could
>> benefit from the discussion. Imacat did not post all comments, only
>> the link that was the catalyst, since they were made in private, it's
>> up to others to bring their constructive thoughts here.
>>
>> I think I see a potential for collaboration between the various ODF
>> related projects here.
>>
>> Can a few sample documents be created which produce graphs showing
>> better performance in other ODF products? Michael, you say they can do
>> that for LO, I invite you to do so. Such documents would help AOO
>> developers explore weakness in AOO code.
>>
>> At the same time AOO could provide documents that demonstrate better
>> AOO performance. These will help other projects explore weaknesses in
>> their own code.
>>
>> RANDOM THOUGHT: are there any ODF test documents that might serve this purpose?
>>
>
> Another idea: the blog post also indicates that AOO 3.4 uses less RAM
> than LO: 35Mb versus 43MB. This might be related to the start up
> performance difference. But since neither product has made radical
> changes to internal memory structures, any difference in memory
> consumption is probably related to what libraries are loaded at
> startup. That should be easier to track down.
>
> Also, a comparison of AOO 3.4 versus OOo 3.3.0 would indicate whether
> we're dealing with a coding improvement in AOO 3.4 or a regression in
> LO. Whatever the result, that gives useful information that can be
> used to improve performance.
>
A quick test suggests a little of both:
Looking soffice.bin ("working set" memory footprint in Windows XP) for
Writer start up, no document loaded:
OOo 3.3.0 = 95,792 Kb
AOO 3.4.0 = 88,508 Kb
LO 3.5.1 = 108,120 Kb
So compared to OOo 3.3.0, AOO 3.4 is reduced 8% and LO increased 13%.
Of course, RAM is (relatively) cheap, so the raw numbers are not that
important. But any associated initialization code associated with
whatever is causing this difference, that could easily impact start
performance.
> -Rob
>
>> Ross
>>
>> On 10 May 2012 10:25, imacat <im...@mail.imacat.idv.tw> wrote:
>>> FYI ^_*'
>>> Please do not attack any party, or create any FUD.
>>>
>>> ------- Original mail -------
>>> Subject: Performance!
>>> Date: Wed, 09 May 2012 23:51:47 +0200
>>> From: Armin Le Grand <ar...@me.com>
>>>
>>> Nice read: http://tinyurl.com/c24awgq
>>>
>>> --
>>> ALG (iPad)
>>>
>>> --
>>> Best regards,
>>> imacat ^_*' <im...@mail.imacat.idv.tw>
>>> PGP Key http://www.imacat.idv.tw/me/pgpkey.asc
>>>
>>> <<Woman's Voice>> News: http://www.wov.idv.tw/
>>> Tavern IMACAT's http://www.imacat.idv.tw/
>>> Woman in FOSS in Taiwan http://wofoss.blogspot.com/
>>> Apache OpenOffice http://www.openoffice.org/
>>> EducOO/OOo4Kids Taiwan http://www.educoo.tw/
>>>
>>
>>
>>
>> --
>> Ross Gardler (@rgardler)
>> Programme Leader (Open Development)
>> OpenDirective http://opendirective.com
Re: Performance!
Posted by Rob Weir <ro...@apache.org>.
On Thu, May 10, 2012 at 6:53 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> Thanks Imacat,
>
> This was originally posted to the private list so as not to offend
> some of our more sensitive list subscribers. However, some useful
> discussion started looking at why the graphs looked like they did. I,
> as a mentor, requested that it be moved here so that everyone, could
> benefit from the discussion. Imacat did not post all comments, only
> the link that was the catalyst, since they were made in private, it's
> up to others to bring their constructive thoughts here.
>
> I think I see a potential for collaboration between the various ODF
> related projects here.
>
> Can a few sample documents be created which produce graphs showing
> better performance in other ODF products? Michael, you say they can do
> that for LO, I invite you to do so. Such documents would help AOO
> developers explore weakness in AOO code.
>
> At the same time AOO could provide documents that demonstrate better
> AOO performance. These will help other projects explore weaknesses in
> their own code.
>
> RANDOM THOUGHT: are there any ODF test documents that might serve this purpose?
>
Another idea: the blog post also indicates that AOO 3.4 uses less RAM
than LO: 35Mb versus 43MB. This might be related to the start up
performance difference. But since neither product has made radical
changes to internal memory structures, any difference in memory
consumption is probably related to what libraries are loaded at
startup. That should be easier to track down.
Also, a comparison of AOO 3.4 versus OOo 3.3.0 would indicate whether
we're dealing with a coding improvement in AOO 3.4 or a regression in
LO. Whatever the result, that gives useful information that can be
used to improve performance.
-Rob
> Ross
>
> On 10 May 2012 10:25, imacat <im...@mail.imacat.idv.tw> wrote:
>> FYI ^_*'
>> Please do not attack any party, or create any FUD.
>>
>> ------- Original mail -------
>> Subject: Performance!
>> Date: Wed, 09 May 2012 23:51:47 +0200
>> From: Armin Le Grand <ar...@me.com>
>>
>> Nice read: http://tinyurl.com/c24awgq
>>
>> --
>> ALG (iPad)
>>
>> --
>> Best regards,
>> imacat ^_*' <im...@mail.imacat.idv.tw>
>> PGP Key http://www.imacat.idv.tw/me/pgpkey.asc
>>
>> <<Woman's Voice>> News: http://www.wov.idv.tw/
>> Tavern IMACAT's http://www.imacat.idv.tw/
>> Woman in FOSS in Taiwan http://wofoss.blogspot.com/
>> Apache OpenOffice http://www.openoffice.org/
>> EducOO/OOo4Kids Taiwan http://www.educoo.tw/
>>
>
>
>
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com
Re: Performance!
Posted by Ross Gardler <rg...@opendirective.com>.
Thanks Imacat,
This was originally posted to the private list so as not to offend
some of our more sensitive list subscribers. However, some useful
discussion started looking at why the graphs looked like they did. I,
as a mentor, requested that it be moved here so that everyone, could
benefit from the discussion. Imacat did not post all comments, only
the link that was the catalyst, since they were made in private, it's
up to others to bring their constructive thoughts here.
I think I see a potential for collaboration between the various ODF
related projects here.
Can a few sample documents be created which produce graphs showing
better performance in other ODF products? Michael, you say they can do
that for LO, I invite you to do so. Such documents would help AOO
developers explore weakness in AOO code.
At the same time AOO could provide documents that demonstrate better
AOO performance. These will help other projects explore weaknesses in
their own code.
RANDOM THOUGHT: are there any ODF test documents that might serve this purpose?
Ross
On 10 May 2012 10:25, imacat <im...@mail.imacat.idv.tw> wrote:
> FYI ^_*'
> Please do not attack any party, or create any FUD.
>
> ------- Original mail -------
> Subject: Performance!
> Date: Wed, 09 May 2012 23:51:47 +0200
> From: Armin Le Grand <ar...@me.com>
>
> Nice read: http://tinyurl.com/c24awgq
>
> --
> ALG (iPad)
>
> --
> Best regards,
> imacat ^_*' <im...@mail.imacat.idv.tw>
> PGP Key http://www.imacat.idv.tw/me/pgpkey.asc
>
> <<Woman's Voice>> News: http://www.wov.idv.tw/
> Tavern IMACAT's http://www.imacat.idv.tw/
> Woman in FOSS in Taiwan http://wofoss.blogspot.com/
> Apache OpenOffice http://www.openoffice.org/
> EducOO/OOo4Kids Taiwan http://www.educoo.tw/
>
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: Fwd: Performance!
Posted by Rory O'Farrell <of...@iol.ie>.
On Thu, 10 May 2012 07:45:24 -0400
Rob Weir <ro...@apache.org> wrote:
> On Thu, May 10, 2012 at 6:28 AM, Michael Meeks <mi...@suse.com> wrote:
> >
> > On Thu, 2012-05-10 at 17:25 +0800, imacat wrote:
> >> Please do not attack any party, or create any FUD.
> > ...
> >
> > Thanks imacat.
> >
> >> Subject: Performance!
> >> Date: Wed, 09 May 2012 23:51:47 +0200
> >> From: Armin Le Grand <ar...@me.com>
> >>
> >> Nice read: http://tinyurl.com/c24awgq
> >
> > I'm always somewhat amused to see statistics on my private blog,
> > quickly labelled FUD (with little-to-no justification or measured
> > attempt at reproducing them more accurately).
> >
> > However promoting studies on the official Apache OpenOffice Google+
> > account to a performance comparison with these minor weaknesses:
> >
> > + non-available reference documents
> > => fundamentally un-repeatable
> > + no details on timing methodology "seconds to load"
> > => but with data accurate to 1/10th of a second
> > + no raw data & => no error bars
> >
> > Is not FUD :-) I mean, I personally like performance comparisons, I can
> > easily believe there is some performance gap in some areas - and I'm
> > eager to find and fix it - but it is deeply frustrating to not be able
> > to.
> >
>
> And so you posted questions on his blog, seeking clarifications on
> methodology, and he responded. Ironically, this is something that is
> not possible for readers of your blog to do, since you do not permit
> comments.
>
> > I'm sure at least the original poster does this in good faith, but it
> > is reasonably trivial to find operations that perform worse by a whole
> > computational order in Apache OpenOffice (incubating).
> >
> > Worse - I am convinced there are double standards here. Were I to go
> > and produce a similar graph in the opposite direction, even if I cite
> > the documents carefully, with methodology, raw data etc. and produce a
> > nice clear private blog post - I am certain it would be instantly
> > dismissed as FUD from TDF - right ? ;-)
> >
> > Ho hum,
> >
> > Michael.
> >
> > --
Rob, please stop being _so confrontational_. There is an old saying about "two wrongs not making a right".
If I were list supervisor I'd be taking a very strict view of reply ethics and I'd start throwing out bannings left right and centre.
--
Rory O'Farrell <of...@iol.ie>
Re: Fwd: Performance!
Posted by Michael Meeks <mi...@suse.com>.
On Thu, 2012-05-10 at 07:45 -0400, Rob Weir wrote:
> And so you posted questions on his blog, seeking clarifications on
> methodology, and he responded.
Apparently my general concern around promoting such content as being
FUD per-se is hard to answer :-) The only interesting thing to me about
this rather silly type of accusation is the simultaneous strenuous
criticism of such things, while doing them yourself :-)
Anyhow lets look at the rather tangential issue of my blog allowing
comments:
> Ironically, this is something that is not possible for readers
> of your blog to do, since you do not permit comments.
Uninteresting as it is - I've been blogging since 1999 and happen to do
it in emacs, in a plain text format; and I host it as flat files: that's
a habit I have no interest in breaking for some hideous, newfangled
databased backed, hosted service etc. :-) But I like feedback, and
update entries with it as/when people send it in, my blog page footer
reads:
"I encourage linking back (of course) to help people decide for
themselves, in context, in the battle for ideas, and I love
fixes / improvements / corrections by private mail."
Back in the day, people used to discuss and cross link their blogs, and
use E-mail - perhaps I'm stuck in that past. As I say, I hear a lot of
"FUD allegations" coming from various people - yet seldom any sort of
reasoned or detailed rebuttal. I would expect such a thing to happen in
a blog entry elsewhere that I can link to in an interesting, civil
discussion, as we go deeper on any given topic over time.
No doubt it is mutually frustrating to misunderstand how to interact
with my blog posts ;-) I'm sorry if that is so, I am happy to link to
contrary data along with a discussion of it, that would be my pattern
here eg. http://www.gnome.org/~michael/blog/2012-03-14.html if you have
a response backing up your claim, I'd be happy to link to it & continue
the debate.
But I suspect all of that is rather beside the point. Statistics are a
very useful tool for comparisons, but they (clearly) have to be used
carefully; I try to do that, and try to show my working too so others
can decide for themselves.
All the best,
Michael.
--
michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
Re: Fwd: Performance!
Posted by Rob Weir <ro...@apache.org>.
On Thu, May 10, 2012 at 6:28 AM, Michael Meeks <mi...@suse.com> wrote:
>
> On Thu, 2012-05-10 at 17:25 +0800, imacat wrote:
>> Please do not attack any party, or create any FUD.
> ...
>
> Thanks imacat.
>
>> Subject: Performance!
>> Date: Wed, 09 May 2012 23:51:47 +0200
>> From: Armin Le Grand <ar...@me.com>
>>
>> Nice read: http://tinyurl.com/c24awgq
>
> I'm always somewhat amused to see statistics on my private blog,
> quickly labelled FUD (with little-to-no justification or measured
> attempt at reproducing them more accurately).
>
> However promoting studies on the official Apache OpenOffice Google+
> account to a performance comparison with these minor weaknesses:
>
> + non-available reference documents
> => fundamentally un-repeatable
> + no details on timing methodology "seconds to load"
> => but with data accurate to 1/10th of a second
> + no raw data & => no error bars
>
> Is not FUD :-) I mean, I personally like performance comparisons, I can
> easily believe there is some performance gap in some areas - and I'm
> eager to find and fix it - but it is deeply frustrating to not be able
> to.
>
And so you posted questions on his blog, seeking clarifications on
methodology, and he responded. Ironically, this is something that is
not possible for readers of your blog to do, since you do not permit
comments.
> I'm sure at least the original poster does this in good faith, but it
> is reasonably trivial to find operations that perform worse by a whole
> computational order in Apache OpenOffice (incubating).
>
> Worse - I am convinced there are double standards here. Were I to go
> and produce a similar graph in the opposite direction, even if I cite
> the documents carefully, with methodology, raw data etc. and produce a
> nice clear private blog post - I am certain it would be instantly
> dismissed as FUD from TDF - right ? ;-)
>
> Ho hum,
>
> Michael.
>
> --
> michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
>
Re: Fwd: Performance!
Posted by Andre Fischer <af...@a-w-f.de>.
On 10.05.2012 12:28, Michael Meeks wrote:
>
> On Thu, 2012-05-10 at 17:25 +0800, imacat wrote:
>> Please do not attack any party, or create any FUD.
> ...
>
> Thanks imacat.
>
>> Subject: Performance!
>> Date: Wed, 09 May 2012 23:51:47 +0200
>> From: Armin Le Grand<ar...@me.com>
>>
>> Nice read: http://tinyurl.com/c24awgq
>
> I'm always somewhat amused to see statistics on my private blog,
> quickly labelled FUD (with little-to-no justification or measured
> attempt at reproducing them more accurately).
>
> However promoting studies on the official Apache OpenOffice Google+
> account to a performance comparison with these minor weaknesses:
>
> + non-available reference documents
> => fundamentally un-repeatable
> + no details on timing methodology "seconds to load"
> => but with data accurate to 1/10th of a second
> + no raw data& => no error bars
I agree. But at least this was posted on a blog that allows comments,
where one can point out these weaknesses (as you apparently already have
discovered). Something that is not possible for all such comparisons.
>
> Is not FUD :-) I mean, I personally like performance comparisons, I can
> easily believe there is some performance gap in some areas - and I'm
> eager to find and fix it - but it is deeply frustrating to not be able
> to.
>
> I'm sure at least the original poster does this in good faith, but it
> is reasonably trivial to find operations that perform worse by a whole
> computational order in Apache OpenOffice (incubating).
Ah, it is good that we agree on this one, too. Your point is proven by
other, similar postings.
>
> Worse - I am convinced there are double standards here.
Again, I agree, double standards, and not just here.
> Were I to go
> and produce a similar graph in the opposite direction, even if I cite
> the documents carefully, with methodology, raw data etc. and produce a
> nice clear private blog post - I am certain it would be instantly
> dismissed as FUD from TDF - right ? ;-)
Yes, that may be so. But then again, statistics are only as good as the
intentions of their creators. I personally don't care much for such
comparisons, regardless of whether I like or dislike the result.
Best regards,
Andre
Re: Fwd: Performance!
Posted by imacat <im...@mail.imacat.idv.tw>.
On 01.05.11 12:22am, Rob Weir said:
> On Thu, May 10, 2012 at 6:28 AM, Michael Meeks <mi...@suse.com> wrote:
>> On Thu, 2012-05-10 at 17:25 +0800, imacat wrote:
>>> Please do not attack any party, or create any FUD.
>
> Well, it looks like ...
> -Rob
Rob,
Could you please stop this, will you? You did not get my point. I
do not care what Meeks said. I feel regretful to myself for posting this.
Meeks,
Do not thank me unless you stop, too.
--
Best regards,
imacat ^_*' <im...@mail.imacat.idv.tw>
PGP Key http://www.imacat.idv.tw/me/pgpkey.asc
<<Woman's Voice>> News: http://www.wov.idv.tw/
Tavern IMACAT's http://www.imacat.idv.tw/
Woman in FOSS in Taiwan http://wofoss.blogspot.com/
Apache OpenOffice http://www.openoffice.org/
EducOO/OOo4Kids Taiwan http://www.educoo.tw/
Re: Fwd: Performance!
Posted by Tor Lillqvist <tm...@iki.fi>.
> Note that this might not have been found (or fixed), without choice
> and competition in the market, provided by Apache OpenOffice. So
> already, AOO 3.4 barely a day old, and we've already helped improve
> LibreOffice.
Note that the bug Caolán's message is about was reported on 2012-03-21
and fixed on 2012-05-03 in the development branch ("master"). I.e.
long before your 3.4 release. Caolán's message is about cherry-picking
that fix also to our stable 3.5 branch.
Also note that the change that caused the slowdown was a sanity check
against malformed document files, so it is a *good* thing that LO has
that change.
(Without the actual sample doc used by the blogger who caused this
thread, we don't know if that is the same performance problem.)
--tml
Re: Fwd: Performance!
Posted by Rob Weir <ro...@apache.org>.
On Thu, May 10, 2012 at 6:28 AM, Michael Meeks <mi...@suse.com> wrote:
>
> On Thu, 2012-05-10 at 17:25 +0800, imacat wrote:
>> Please do not attack any party, or create any FUD.
> ...
>
> Thanks imacat.
>
>> Subject: Performance!
>> Date: Wed, 09 May 2012 23:51:47 +0200
>> From: Armin Le Grand <ar...@me.com>
>>
>> Nice read: http://tinyurl.com/c24awgq
>
> I'm always somewhat amused to see statistics on my private blog,
> quickly labelled FUD (with little-to-no justification or measured
> attempt at reproducing them more accurately).
>
> However promoting studies on the official Apache OpenOffice Google+
> account to a performance comparison with these minor weaknesses:
>
> + non-available reference documents
> => fundamentally un-repeatable
> + no details on timing methodology "seconds to load"
> => but with data accurate to 1/10th of a second
> + no raw data & => no error bars
>
> Is not FUD :-) I mean, I personally like performance comparisons, I can
> easily believe there is some performance gap in some areas - and I'm
> eager to find and fix it - but it is deeply frustrating to not be able
> to.
Well, it looks like LO overcame the poor quality of the performance
data, the lack of a methodology document and the failure of the
blogger to provide error bars and p-values, and despite this great
adversity managed to confirm that in fact this was a performance
regression in LibreOffice:
See last comment here:
http://www.hostcult.com/2012/05/apache-openoffice-34-vs-libreoffice-353.html
and see the post here:
http://lists.freedesktop.org/archives/libreoffice/2012-May/031523.html
Note that this might not have been found (or fixed), without choice
and competition in the market, provided by Apache OpenOffice. So
already, AOO 3.4 barely a day old, and we've already helped improve
LibreOffice. This is good news, I think.
-Rob
Re: Fwd: Performance!
Posted by Michael Meeks <mi...@suse.com>.
On Thu, 2012-05-10 at 17:25 +0800, imacat wrote:
> Please do not attack any party, or create any FUD.
...
Thanks imacat.
> Subject: Performance!
> Date: Wed, 09 May 2012 23:51:47 +0200
> From: Armin Le Grand <ar...@me.com>
>
> Nice read: http://tinyurl.com/c24awgq
I'm always somewhat amused to see statistics on my private blog,
quickly labelled FUD (with little-to-no justification or measured
attempt at reproducing them more accurately).
However promoting studies on the official Apache OpenOffice Google+
account to a performance comparison with these minor weaknesses:
+ non-available reference documents
=> fundamentally un-repeatable
+ no details on timing methodology "seconds to load"
=> but with data accurate to 1/10th of a second
+ no raw data & => no error bars
Is not FUD :-) I mean, I personally like performance comparisons, I can
easily believe there is some performance gap in some areas - and I'm
eager to find and fix it - but it is deeply frustrating to not be able
to.
I'm sure at least the original poster does this in good faith, but it
is reasonably trivial to find operations that perform worse by a whole
computational order in Apache OpenOffice (incubating).
Worse - I am convinced there are double standards here. Were I to go
and produce a similar graph in the opposite direction, even if I cite
the documents carefully, with methodology, raw data etc. and produce a
nice clear private blog post - I am certain it would be instantly
dismissed as FUD from TDF - right ? ;-)
Ho hum,
Michael.
--
michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
Re: Performance!
Posted by Roberto Galoppini <rg...@geek.net>.
On Fri, May 11, 2012 at 6:34 PM, Dennis E. Hamilton <dennis.hamilton@acm.org
> wrote:
> I believe the correct baseline is neither LO nor Microsoft Office, but
> OpenOffice.org 3.3.0. And then successive versions of AOO starting with
> 3.4. It is the performance that this project has some responsibility for.
> LO and MSO performance are someone else's business.
>
+1
I totally buy your line of thought. Think we should learn from Gillette,
and its 'positive cannibalization', i.e. focusing its marketing resources
on switching its own customers from N-1 to N release. Why that? Because
openofffice _is_ the open source market leader, and the number of actual
users is big enough to play à la Gillette. Anything else is just boring.
My two cents,
Roberto
>
> It is useful to know about interoperability performance cases if there is
> a situation where users of AOO are thwarted by a capacity, functionality,
> or speed issue that matters in accomplishing their work. That also alerts
> us to areas for us to work on. But serious quantitative assessment is a
> technical matter and it needs to be focused on our product, not one that is
> not our responsibility.
>
> - Dennis
>
> -----Original Message-----
> From: Xia Zhao [mailto:lilyzhao8@gmail.com]
> Sent: Friday, May 11, 2012 02:27
> To: ooo-dev@incubator.apache.org
> Subject: Re: Performance!
>
> I have replied in private mail list... And now replied here again.
>
> Usually we should have AOO 3.4 performance data before we ship it..... What
> we should do now is building the performance baseline for AOO 3.4, and
> comparing with LO and MS office. Actually we are doing that now, try to
> build AOO 3.4 performance baseline using automation tool proposed in the
> community, that is, GUI+Lib. But it need time.
>
> I'd like give manual performance data for AOO 3.4 first. I have had some of
> the data.
>
> Best regards,
>
> Lily
>
> 2012/5/10 imacat <im...@mail.imacat.idv.tw>
>
> > FYI ^_*'
> > Please do not attack any party, or create any FUD.
> >
> > ------- Original mail -------
> > Subject: Performance!
> > Date: Wed, 09 May 2012 23:51:47 +0200
> > From: Armin Le Grand <ar...@me.com>
> >
> > Nice read: http://tinyurl.com/c24awgq
> >
> > --
> > ALG (iPad)
> >
> > --
> > Best regards,
> > imacat ^_*' <im...@mail.imacat.idv.tw>
> > PGP Key http://www.imacat.idv.tw/me/pgpkey.asc
> >
> > <<Woman's Voice>> News: http://www.wov.idv.tw/
> > Tavern IMACAT's http://www.imacat.idv.tw/
> > Woman in FOSS in Taiwan http://wofoss.blogspot.com/
> > Apache OpenOffice http://www.openoffice.org/
> > EducOO/OOo4Kids Taiwan http://www.educoo.tw/
> >
> >
>
>
--
====
This e- mail message is intended only for the named recipient(s) above. It
may contain confidential and privileged information. If you are not the
intended recipient you are hereby notified that any dissemination,
distribution or copying of this e-mail and any attachment(s) is strictly
prohibited. If you have received this e-mail in error, please immediately
notify the sender by replying to this e-mail and delete the message and any
attachment(s) from your system. Thank you.
RE: Performance!
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I believe the correct baseline is neither LO nor Microsoft Office, but OpenOffice.org 3.3.0. And then successive versions of AOO starting with 3.4. It is the performance that this project has some responsibility for. LO and MSO performance are someone else's business.
It is useful to know about interoperability performance cases if there is a situation where users of AOO are thwarted by a capacity, functionality, or speed issue that matters in accomplishing their work. That also alerts us to areas for us to work on. But serious quantitative assessment is a technical matter and it needs to be focused on our product, not one that is not our responsibility.
- Dennis
-----Original Message-----
From: Xia Zhao [mailto:lilyzhao8@gmail.com]
Sent: Friday, May 11, 2012 02:27
To: ooo-dev@incubator.apache.org
Subject: Re: Performance!
I have replied in private mail list... And now replied here again.
Usually we should have AOO 3.4 performance data before we ship it..... What
we should do now is building the performance baseline for AOO 3.4, and
comparing with LO and MS office. Actually we are doing that now, try to
build AOO 3.4 performance baseline using automation tool proposed in the
community, that is, GUI+Lib. But it need time.
I'd like give manual performance data for AOO 3.4 first. I have had some of
the data.
Best regards,
Lily
2012/5/10 imacat <im...@mail.imacat.idv.tw>
> FYI ^_*'
> Please do not attack any party, or create any FUD.
>
> ------- Original mail -------
> Subject: Performance!
> Date: Wed, 09 May 2012 23:51:47 +0200
> From: Armin Le Grand <ar...@me.com>
>
> Nice read: http://tinyurl.com/c24awgq
>
> --
> ALG (iPad)
>
> --
> Best regards,
> imacat ^_*' <im...@mail.imacat.idv.tw>
> PGP Key http://www.imacat.idv.tw/me/pgpkey.asc
>
> <<Woman's Voice>> News: http://www.wov.idv.tw/
> Tavern IMACAT's http://www.imacat.idv.tw/
> Woman in FOSS in Taiwan http://wofoss.blogspot.com/
> Apache OpenOffice http://www.openoffice.org/
> EducOO/OOo4Kids Taiwan http://www.educoo.tw/
>
>
Re: Performance!
Posted by Rob Weir <ro...@apache.org>.
On Fri, May 11, 2012 at 5:26 AM, Xia Zhao <li...@gmail.com> wrote:
> I have replied in private mail list... And now replied here again.
>
> Usually we should have AOO 3.4 performance data before we ship it..... What
> we should do now is building the performance baseline for AOO 3.4, and
> comparing with LO and MS office. Actually we are doing that now, try to
Would be good to compare to OOo 3.3.0 also.
-Rob
> build AOO 3.4 performance baseline using automation tool proposed in the
> community, that is, GUI+Lib. But it need time.
>
> I'd like give manual performance data for AOO 3.4 first. I have had some of
> the data.
>
> Best regards,
>
> Lily
>
> 2012/5/10 imacat <im...@mail.imacat.idv.tw>
>
>> FYI ^_*'
>> Please do not attack any party, or create any FUD.
>>
>> ------- Original mail -------
>> Subject: Performance!
>> Date: Wed, 09 May 2012 23:51:47 +0200
>> From: Armin Le Grand <ar...@me.com>
>>
>> Nice read: http://tinyurl.com/c24awgq
>>
>> --
>> ALG (iPad)
>>
>> --
>> Best regards,
>> imacat ^_*' <im...@mail.imacat.idv.tw>
>> PGP Key http://www.imacat.idv.tw/me/pgpkey.asc
>>
>> <<Woman's Voice>> News: http://www.wov.idv.tw/
>> Tavern IMACAT's http://www.imacat.idv.tw/
>> Woman in FOSS in Taiwan http://wofoss.blogspot.com/
>> Apache OpenOffice http://www.openoffice.org/
>> EducOO/OOo4Kids Taiwan http://www.educoo.tw/
>>
>>
Re: Performance!
Posted by Chao Huang <ch...@gmail.com>.
2012/5/11 Xia Zhao <li...@gmail.com>
> I have replied in private mail list... And now replied here again.
>
> Usually we should have AOO 3.4 performance data before we ship it..... What
> we should do now is building the performance baseline for AOO 3.4, and
> comparing with LO and MS office. Actually we are doing that now, try to
> build AOO 3.4 performance baseline using automation tool proposed in the
> community, that is, GUI+Lib. But it need time.
>
>
> I'd like give manual performance data for AOO 3.4 first. I have had some of
> the data.
>
It's great to have a baseline for performance data. Thanks!
>
> Best regards,
>
> Lily
>
> 2012/5/10 imacat <im...@mail.imacat.idv.tw>
>
> > FYI ^_*'
> > Please do not attack any party, or create any FUD.
> >
> > ------- Original mail -------
> > Subject: Performance!
> > Date: Wed, 09 May 2012 23:51:47 +0200
> > From: Armin Le Grand <ar...@me.com>
> >
> > Nice read: http://tinyurl.com/c24awgq
> >
> > --
> > ALG (iPad)
> >
> > --
> > Best regards,
> > imacat ^_*' <im...@mail.imacat.idv.tw>
> > PGP Key http://www.imacat.idv.tw/me/pgpkey.asc
> >
> > <<Woman's Voice>> News: http://www.wov.idv.tw/
> > Tavern IMACAT's http://www.imacat.idv.tw/
> > Woman in FOSS in Taiwan http://wofoss.blogspot.com/
> > Apache OpenOffice http://www.openoffice.org/
> > EducOO/OOo4Kids Taiwan http://www.educoo.tw/
> >
> >
>
--
Best regards,
Chao Huang
Re: Performance!
Posted by Xia Zhao <li...@gmail.com>.
I have replied in private mail list... And now replied here again.
Usually we should have AOO 3.4 performance data before we ship it..... What
we should do now is building the performance baseline for AOO 3.4, and
comparing with LO and MS office. Actually we are doing that now, try to
build AOO 3.4 performance baseline using automation tool proposed in the
community, that is, GUI+Lib. But it need time.
I'd like give manual performance data for AOO 3.4 first. I have had some of
the data.
Best regards,
Lily
2012/5/10 imacat <im...@mail.imacat.idv.tw>
> FYI ^_*'
> Please do not attack any party, or create any FUD.
>
> ------- Original mail -------
> Subject: Performance!
> Date: Wed, 09 May 2012 23:51:47 +0200
> From: Armin Le Grand <ar...@me.com>
>
> Nice read: http://tinyurl.com/c24awgq
>
> --
> ALG (iPad)
>
> --
> Best regards,
> imacat ^_*' <im...@mail.imacat.idv.tw>
> PGP Key http://www.imacat.idv.tw/me/pgpkey.asc
>
> <<Woman's Voice>> News: http://www.wov.idv.tw/
> Tavern IMACAT's http://www.imacat.idv.tw/
> Woman in FOSS in Taiwan http://wofoss.blogspot.com/
> Apache OpenOffice http://www.openoffice.org/
> EducOO/OOo4Kids Taiwan http://www.educoo.tw/
>
>