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

[Sebastian Markbåge]

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.