SVG in Firebug, large memory leak?
Steven Roussey
http://fbug.googlecode.com/issues/attachment?aid=4515682982516050731&name=firebug-1.5b8pre-r5349.xpi
And going to this site:
http://tutorials.jenkov.com/svg/svg-examples.html
And right-clicking on some SVG thing like the circle or rectange, and
you see something like this:
http://fbug.googlecode.com/issues/attachment?aid=1877902685949581625&name=Capture.PNG&inline=1
Now if you play in the style tab and turn on/off the fill and stroke,
etc a few times you can see the memory usage go up megabytes at a
time. Hitting reload makes it worse. I don't know what would be
causing such a heavy memory usage. Any ideas?
-steve--
Boris Zbarsky
> Now if you play in the style tab and turn on/off the fill and stroke,
> etc a few times
This part could really use more specific directions.
> I don't know what would be
> causing such a heavy memory usage. Any ideas?
Not offhand, though there are several options: it could be Firebug
itself, it could be the SVG code, etc.
What exactly happens when you "turn on/off" those properties, on the
code level?
-Boris
Steven Roussey
> On 12/18/09 12:14 AM, Steven Roussey wrote:
>
> > Now if you play in the style tab and turn on/off the fill and stroke,
> > etc a few times
>
> This part could really use more specific directions.
In the image here:
http://fbug.googlecode.com/issues/attachment?aid=1877902685949581625&name=Capture.PNG&inline=1
On the right side of the image you see the Style panel. If you hover
over the style info there you see a shaded out 'x' appear which lets
you turn that style off and on. For example, clicking to the left of
"fill: #6666ff" removes the style temporarily. Changing the color has
a similar effect.
> > I don't know what would be
> > causing such a heavy memory usage. Any ideas?
>
> Not offhand, though there are several options: it could be Firebug
> itself, it could be the SVG code, etc.
>
> What exactly happens when you "turn on/off" those properties, on the
> code level?
Since it is an inline style, it should just be changing the SVG
element's style attribute. There is no special code at the point for
SVG. I was a little surprised it all worked.
-steve--
Boris Zbarsky
> Since it is an inline style, it should just be changing the SVG
> element's style attribute.
And storing the old value somewhere, right? Or something? And
rebuilding the entire HTML view using domplate in the process?
My current suspicion, and one I've been meaning to investigate for a
bit, is that domplate leaks somehow. Does performing the same style
change that Firebug is doing here directly through script cause the same
memory issue? Does disabling the domplate mutation observers cause the
issue to go away?
-Boris
Steven Roussey
> On 12/18/09 9:04 AM, Steven Roussey wrote:
>
> > Since it is an inline style, it should just be changing the SVG
> > element's style attribute.
>
> And storing the old value somewhere, right? Or something? And
> rebuilding the entire HTML view using domplate in the process?
Yes on the storing the old value somewhere. I have tried to keep my
code changes and bug fixes contained to the html panel, though I have
been changing the layout panel recently. And there are a few things in
the CSS panel I'd like to change, so I will hopefully know the answer
to that question when I look at that code.
It does not rebuild the entire HTML view AFAIK. It invalidates a node
(and its children), and since we are at the leaf level, I don't think
it is much. Notice how I said I think. I haven't had a need to look
into it very deeply thus far.
> My current suspicion, and one I've been meaning to investigate for a
> bit, is that domplate leaks somehow. Does performing the same style
> change that Firebug is doing here directly through script cause the same
> memory issue? Does disabling the domplate mutation observers cause the
> issue to go away?
>
> -Boris
I guess I can add some temp UI to turn the observers on and off and
test that theory, mabye as an extension to firebug. Can't just comment
them out of the code though.
I'm guessing that domplate was written a looong time ago. I don't know
how careful the author was in handling dom references, for example. In
domplate or everywhere.
I started a project to use a more modern js lib for a firebug UI
(skipping xul altogether) and run it in jetpack (or another browser,
which would let me use another cpu core) and communicate back to the
firebug core. The communication gateway, crossfire, is new and jetpack
is new, and my code is new, and all that newness means bugs and I
loose my patience for the side project. Next year...
-steve--
Boris Zbarsky
> It does not rebuild the entire HTML view AFAIK. It invalidates a node
> (and its children), and since we are at the leaf level, I don't think
> it is much. Notice how I said I think. I haven't had a need to look
> into it very deeply thus far.
Please do? From what I've seen, the domplate setup is a huge
performance cost when using Firebug.
> I guess I can add some temp UI to turn the observers on and off and
> test that theory, mabye as an extension to firebug. Can't just comment
> them out of the code though.
Why not, as a test? I'd do it if I knew where the code lives; you're a
lot more familiar with it than I am.
> I'm guessing that domplate was written a looong time ago. I don't know
> how careful the author was in handling dom references, for example. In
> domplate or everywhere.
Yes on all points. Which doesn't help our users one bit.
To be clear, as far as I can tell from my limited testing Firebug leaks
every single DOM object it ever touches, for the lifetime of the app.
At least in some cases. Fixing this should probably be a #1 priority
for Firebug... It's on my list of things to look into, but if someone
with more familiarity with the Firebug code is willing to help out, that
would help a lot.
-Boris
Steven Roussey
> To be clear, as far as I can tell from my limited testing Firebug leaks
> every single DOM object it ever touches, for the lifetime of the app.
> At least in some cases. Fixing this should probably be a #1 priority
> for Firebug... It's on my list of things to look into, but if someone
> with more familiarity with the Firebug code is willing to help out, that
> would help a lot.
Dealing with memory leaks sounds a lot like a day job. ;) I'm used to
finding leaks on IE, at which point if fixed there it is fixed
everywhere. What tools are available in Firefox?
-steve--
Boris Zbarsky
> Dealing with memory leaks sounds a lot like a day job. ;) I'm used to
> finding leaks on IE, at which point if fixed there it is fixed
> everywhere. What tools are available in Firefox?
The problem is that these aren't actual leaks in the C sense. They're
just Firebug holding references to stuff for the lifetime of the app,
then dropping them at shutdown (at least if I'm right that there are
app-lifetime leaks). So your typical tools won't help much...
-Boris
John J Barton
> Using this version of Firebug:
>
> http://fbug.googlecode.com/issues/attachment?aid=4515682982516050731&name=firebug-1.5b8pre-r5349.xpi
>
> And going to this site:
>
> http://tutorials.jenkov.com/svg/svg-examples.html
>
> And right-clicking on some SVG thing like the circle or rectange, and
> you see something like this:
>
> http://fbug.googlecode.com/issues/attachment?aid=1877902685949581625&name=Capture.PNG&inline=1
>
> Now if you play in the style tab and turn on/off the fill and stroke,
> etc a few times you can see the memory usage go up megabytes at a
> time.
I repeated this test with Firebug 1.6a1. I saw no memory increase at all
on FF 3.6b6pre/Win XP.
> Hitting reload makes it worse.
I reloaded multiple times, the memory was 87M, 87M, 87M, 90M, 90M, 89M.
Note this was a clean profile with only Firebug and FBTest. Specifically
this was not with Chromebug, which is not able to track windows properly
so it cannot be used for memory tests.
jjb