New implementation of drawinglayer may lead to performance downgrade?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

New implementation of drawinglayer may lead to performance downgrade?

yanmin
Hi Herbert,
A problem need your help again.

The analysis of profiling data indicates the function
*drawinglayer::primitive2d::getB2DRangeFromPrimitive2DSequence
*contributes to performance downgrade during create a new presentation. The
function is called heavily by S*drobject::RecalcBoundRect *which is
associated with creating presentation objects. These functions have been
re-implemented and pretty different with OOo1.x. I know you have given a
speech on the rework of new drawing core on OOoCon2008, so would you please
give some hints or suggestions?

Thank you for kindly help again and again.

Best regards,
--
Jia Yanmin (贾彦民)
IBM China Software Development Laboratory, Beijing
Tel: 8610-82454759  E-Mail:[hidden email] <E-Mail%[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: New implementation of drawinglayer may lead to performance downgrade?

christian.lippka
Hi Jia,

you forgot to state in which version you see the performance problem.
I think that there was already a performance fix in the area of
RecalcBoundRect but I cc'ed Armin to tell us if this is true and in
which version it is fixed.

Regards,
Christian


yanmin wrote:

> Hi Herbert,
> A problem need your help again.
>
> The analysis of profiling data indicates the function
> *drawinglayer::primitive2d::getB2DRangeFromPrimitive2DSequence
> *contributes to performance downgrade during create a new presentation. The
> function is called heavily by S*drobject::RecalcBoundRect *which is
> associated with creating presentation objects. These functions have been
> re-implemented and pretty different with OOo1.x. I know you have given a
> speech on the rework of new drawing core on OOoCon2008, so would you please
> give some hints or suggestions?
>
> Thank you for kindly help again and again.
>
> Best regards,


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New implementation of drawinglayer may lead to performance downgrade?

Herbert Duerr
Hi Yanmin and Christian,

maybe the fix against "excessive reformatting in textboxes" (http://www.openoffice.org/issues/show_bug.cgi?id=83553 
) is the one you are looking for. The fix for that got into DEV300_m52.

On Aug 24, 2009, at 12:16 PM, Christian Lippka wrote:

> you forgot to state in which version you see the performance problem.
> I think that there was already a performance fix in the area of
> RecalcBoundRect but I cc'ed Armin to tell us if this is true and in
> which version it is fixed.
>
> Regards,
> Christian
>
>
> yanmin wrote:
>> Hi Herbert,
>> A problem need your help again.
>>
>> The analysis of profiling data indicates the function
>> *drawinglayer::primitive2d::getB2DRangeFromPrimitive2DSequence
>> *contributes to performance downgrade during create a new  
>> presentation. The
>> function is called heavily by S*drobject::RecalcBoundRect *which is
>> associated with creating presentation objects. These functions have  
>> been
>> re-implemented and pretty different with OOo1.x. I know you have  
>> given a
>> speech on the rework of new drawing core on OOoCon2008, so would  
>> you please
>> give some hints or suggestions?
>>
>> Thank you for kindly help again and again.

---
Herbert Duerr
[hidden email]




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New implementation of drawinglayer may lead to performance downgrade?

yanmin
Hi Herbert and Christian,

Thank you for your information.

2009/8/24 Herbert Duerr <[hidden email]>

> Hi Yanmin and Christian,
>
> maybe the fix against "excessive reformatting in textboxes" (
> http://www.openoffice.org/issues/show_bug.cgi?id=83553) is the one you are
> looking for. The fix for that got into DEV300_m52.


I will forward the issue to the developer who make the analysis of this
porfermance downgrade. Thanks.

>
>
> On Aug 24, 2009, at 12:16 PM, Christian Lippka wrote:
>
>> you forgot to state in which version you see the performance problem.
>> I think that there was already a performance fix in the area of
>> RecalcBoundRect but I cc'ed Armin to tell us if this is true and in
>> which version it is fixed.
>
>
Sorry, I failed to learn the latest change. OOO310_m11 was used to get
profiling data for performance analysis.


>
>>
>> Regards,
>> Christian
>>
>>
>> yanmin wrote:
>>
>>> Hi Herbert,
>>> A problem need your help again.
>>>
>>> The analysis of profiling data indicates the function
>>> *drawinglayer::primitive2d::getB2DRangeFromPrimitive2DSequence
>>> *contributes to performance downgrade during create a new presentation.
>>> The
>>> function is called heavily by S*drobject::RecalcBoundRect *which is
>>> associated with creating presentation objects. These functions have been
>>> re-implemented and pretty different with OOo1.x. I know you have given a
>>> speech on the rework of new drawing core on OOoCon2008, so would you
>>> please
>>> give some hints or suggestions?
>>>
>>> Thank you for kindly help again and again.
>>>
>>
> ---
> Herbert Duerr
> [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Best regards,
Yanmin
Reply | Threaded
Open this post in threaded view
|

Re: New implementation of drawinglayer may lead to performance downgrade?

yanmin
In reply to this post by Herbert Duerr
Hi Herbert,



> maybe the fix against "excessive reformatting in textboxes" (
> http://www.openoffice.org/issues/show_bug.cgi?id=83553) is the one you are
> looking for. The fix for that got into DEV300_m52.


It seems the performance bug reported by ssue 83553 is raised while mouse
moving because of expensive textbox reformatting. But the performance
problem I mensioned happens when creating a new presentation. And the
function drawinglayer::primitive2d::getB2DRangeFromPrimitive2DSequence which
is called heavily by S*drobject::RecalcBoundRect* takes 29% time during the
new presentation process from our profiling data. So a developer is
suspicious that the problem is caused by the code change of drawinglayer or
S*drobject*.


On Aug 24, 2009, at 12:16 PM, Christian Lippka wrote:

> you forgot to state in which version you see the performance problem.
> I think that there was already a performance fix in the area of
> RecalcBoundRect but I cc'ed Armin to tell us if this is true and in
> which version it is fixed.
>
> Regards,
> Christian
>
>
> ---
> Herbert Duerr
> [hidden email]
>

Best regards,
Yanmin
Reply | Threaded
Open this post in threaded view
|

Re: New implementation of drawinglayer may lead to performance downgrade?

Herbert Duerr
Hi Yanmin,

the excessive reformats where the core of the problem. That it  
happened even when nothing was going on (except so seemingly innocent  
actions as just moving the mouse) was the symptom that I reported.  
Because there is quite a difference between "symptom" and "root cause"  
and I prefer to update the issue summary to the root cause of the  
problem as soon as it is fully understood. Other developers prefer to  
keep the summary line exactly as provided by the issue reporter. I  
disagree with this but there is nothing I can do except to lead by  
example.

  AFAIK the root cause of the problem was that the new DrawingLayer  
relied on EditEngine to do the formatting and it didn't keep the  
results. So every time it measured something the DrawingLayer  
reformatted it and measured it. Since our underlying text processing  
is outstandingly fast this problem wasn't noticed for quite a while.

The solution consisted of course in keeping the formatted result. And  
of course the DrawingLayer likes to keep it converted to a bag of  
BasePrimitives. Doing it this way the measurements only need to be  
done once and the base primitives cache the results. So this is the  
reason why I think that the cached results may benefit your case:
- they avoid that EditEngine is requested to do reformats over and over
- they avoid that the same thing is re-measured over and over
=> drawinglayer::primitive2d::getB2DRangeFromPrimitive2DSequence is  
now usually called much less than the gazillion times it was called  
between OOO310 and DEV300_m52

So, there is good reason to expect that the particular problem you are  
seeing is solved in newer DEV300 builds. Please retest the problem.  
Don't take issue summaries verbatim if they were solved by developers  
who don't update their issue summary lines to the root cause of the  
problem.

On Aug 25, 2009, at 6:09 AM, yanmin wrote:

> Hi Herbert,
>
>> maybe the fix against "excessive reformatting in textboxes" (
>> http://www.openoffice.org/issues/show_bug.cgi?id=83553) is the one  
>> you are
>> looking for. The fix for that got into DEV300_m52.
>
>
> It seems the performance bug reported by ssue 83553 is raised while  
> mouse
> moving because of expensive textbox reformatting. But the performance
> problem I mensioned happens when creating a new presentation. And the
> function  
> drawinglayer::primitive2d::getB2DRangeFromPrimitive2DSequence which
> is called heavily by S*drobject::RecalcBoundRect* takes 29% time  
> during the
> new presentation process from our profiling data. So a developer is
> suspicious that the problem is caused by the code change of  
> drawinglayer or
> S*drobject*.
>
> On Aug 24, 2009, at 12:16 PM, Christian Lippka wrote:
>
>> you forgot to state in which version you see the performance problem.
>> I think that there was already a performance fix in the area of
>> RecalcBoundRect but I cc'ed Armin to tell us if this is true and in
>> which version it is fixed.

---
Herbert Duerr
[hidden email]




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Fwd: New implementation of drawinglayer may lead to performance downgrade?

Herbert Duerr
Hi,

on this topic there was a parallel discussion on  
[hidden email] so I'm forwarding my answer here too. I suggest  
that before further talk everyone who had seen the problem in  
 >=DEV300_m29 (where the new DrawingLayer got integrated) should  
retest it with >=DEV300_m52 (where issue 83553 and related issues got  
fixed).

Begin forwarded message:

> From: Herbert Duerr <[hidden email]>
> Date: August 25, 2009 9:10:54 AM GMT+02:00
> To: [hidden email]
> Subject: Re: [gsl-dev] New implementation of drawinglayer may lead  
> to performance downgrade?
>
> Hi Yanmin,
>
> the excessive reformats where the core of the problem. That it  
> happened even when nothing was going on (except so seemingly  
> innocent actions as just moving the mouse) was the symptom that I  
> reported. Because there is quite a difference between "symptom" and  
> "root cause" and I prefer to update the issue summary to the root  
> cause of the problem as soon as it is fully understood. Other  
> developers prefer to keep the summary line exactly as provided by  
> the issue reporter. I disagree with this but there is nothing I can  
> do except to lead by example.
>
> AFAIK the root cause of the problem was that the new DrawingLayer  
> relied on EditEngine to do the formatting and it didn't keep the  
> results. So every time it measured something the DrawingLayer  
> reformatted it and measured it. Since our underlying text processing  
> is outstandingly fast this problem wasn't noticed for quite a while.
>
> The solution consisted of course in keeping the formatted result.  
> And of course the DrawingLayer likes to keep it converted to a bag  
> of BasePrimitives. Doing it this way the measurements only need to  
> be done once and the base primitives cache the results. So this is  
> the reason why I think that the cached results may benefit your case:
> - they avoid that EditEngine is requested to do reformats over and  
> over
> - they avoid that the same thing is re-measured over and over
> => drawinglayer::primitive2d::getB2DRangeFromPrimitive2DSequence is  
> now usually called much less than the gazillion times it was called  
> between OOO310 and DEV300_m52
>
> So, there is good reason to expect that the particular problem you  
> are seeing is solved in newer DEV300 builds. Please retest the  
> problem. Don't take issue summaries verbatim if they were solved by  
> developers who don't update their issue summary lines to the root  
> cause of the problem.
>
> On Aug 25, 2009, at 6:09 AM, yanmin wrote:
>> Hi Herbert,
>>
>>> maybe the fix against "excessive reformatting in textboxes" (
>>> http://www.openoffice.org/issues/show_bug.cgi?id=83553) is the one  
>>> you are
>>> looking for. The fix for that got into DEV300_m52.
>>
>>
>> It seems the performance bug reported by ssue 83553 is raised while  
>> mouse
>> moving because of expensive textbox reformatting. But the performance
>> problem I mensioned happens when creating a new presentation. And the
>> function  
>> drawinglayer::primitive2d::getB2DRangeFromPrimitive2DSequence which
>> is called heavily by S*drobject::RecalcBoundRect* takes 29% time  
>> during the
>> new presentation process from our profiling data. So a developer is
>> suspicious that the problem is caused by the code change of  
>> drawinglayer or
>> S*drobject*.
>>
>> On Aug 24, 2009, at 12:16 PM, Christian Lippka wrote:
>>
>>> you forgot to state in which version you see the performance  
>>> problem.
>>> I think that there was already a performance fix in the area of
>>> RecalcBoundRect but I cc'ed Armin to tell us if this is true and in
>>> which version it is fixed.

---
Herbert Duerr
[hidden email]




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]