Re: [Moo] Re: ART: Bottleneck in ART.SVG._whileInDocument

[Barry van Oudtshoorn]

I've taken your suggestion and moved the measurement code back into an 
explicit method, and the difference is staggering -- the rendering time 
is now less than half of what it was. Thanks!

In the fairly simple charts that I'm rendering, I don't need to measure 
the text (at least, not in any of the cases that I've come up against 
yet!), so for me, this is an all-round win.

Do you know off the top of your head if this is this a Gecko-specific 
problem? If it is, it's probably worth filing a bug on bugzilla. I've 
tried searching for an existing one, but either it doesn't exist, or my 
bugzilla-fu is sadly lacking.

On 29/09/11 02:20, Sebastian Markbåge wrote:
The real issue is this commit: 
https://github.com/calyptus/art/commit/3b2f838dd04d09e89d562a05ce5024812430bfab

We're now always measuring the text. Firefox wants to render it to do
that. Which is why it needs to be in the DOM. It causes reflow, redraw
and other performance intensive stuff.

You'll notice there's a comment to remove this in the draw function of
ART.SVG.Text. The reason we keep it in there is because some APIs
require an object to have an explicit size. These APIs could lazily
call .measure() on the text if they're needed. But I'd rather drop
those APIs. If you don't use those defaults you can move the measuring
code back to the explicit measure function.

(In charts you may want to measure some text anyway. The trick then is
to do it in bulk. For example, put all your text on separate lines and
measure the box to see what's the size of the widest text. You can
also measure text after it's in the DOM. Then it's cheap.)


On Sep 27, 4:36 am, Barry van Oudtshoorn<bvanoudtsho...@gmail.com>
wrote:
Hi!

I'm using ART for a graphing library, and I've found that there seems to
be a significant bottleneck in the _whileInDocument method in
ART.SVG.Text. My guess is that instantiating a new ART.SVG instance,
injecting it into the document, then removing it immediately is what's
causing the slowdown.

I've tracked down the addition of this method to commit c99cca1151
[https://github.com/barryvan/art/tree/c99cca11516bcfd98d81d04dc4ed5750...],
but the commit message doesn't give a very clear indication of what this
function is for, and why it does what it does.

Here's a table with the raw numbers. Note that I've replaced "anonymous"
with the actual function name for the first few, to make it more legible. :)

Total time: 635.212ms
*Function
*       *Calls
*       *Percent
*       *Own time
*       *Time
*       *Average
*       *Min
*       *Max
*       *Source
*
ART.SVG.Text._whileInDocument
         177     49.41%  313.88ms        369.668ms       2.089ms         
1.972ms         2.843ms
ART.SVG.js (line 579)
ART.SVG.Text.draw
         177     8.58%   54.489ms        430.688ms       2.433ms         
2.276ms         3.278ms
ART.SVG.js (line 435)
ART.Element.Inject      875     4.77%   30.271ms        40.665ms        0.046ms 
        0.003ms
0.175ms
ART.js (line 37)
ART.SVG.Base._setColor  1697    2.43%   15.405ms        64.88ms         0.038ms
0.007ms         0.267ms
ART.SVG.js (line 214)
anonymous       510     1.9%    12.051ms        12.051ms        0.024ms         
0.019ms         0.07ms
ART.SVG.js (line 62)
anonymous       1310    1.86%   11.824ms        37.43ms         0.029ms         
0.023ms         0.103ms
ART.Color.js (line 27)
anonymous       354     1.62%   10.294ms        10.294ms        0.029ms         
0.003ms         0.634ms
ART.js (line 43)
anonymous       4064    1.44%   9.175ms         12.128ms        0.003ms         
0ms     0.029ms
mootools-core.js (line 43)
anonymous       1074    1.44%   9.119ms         9.119ms         0.008ms         
0.005ms         0.245ms
ART.SVG.js (line 15)
anonymous       1310    1.18%   7.516ms         16.511ms        0.013ms         
0.009ms         0.088ms
ART.Color.js (line 20)

What I'm wondering is whether there's some way to optimise this --
ideally, we shouldn't be doing this much manipulation using the live
DOM, as it's really slow. :) I'm not actually drawing very much text --
10, 20, .., 100 for the y-axis and maybe 8 labels for the x-axis, across
about 10 graphs; all up, 177 pieces of text, as you can see in the table.

- Barry

--
Barry van Oudtshoornwww.barryvan.com.au

Not sent from my Apple ?Phone.


--
Barry van Oudtshoorn
www.barryvan.com.au

Not sent from my Apple πPhone.