Performance problem identified

0 views
Skip to first unread message

voracity

unread,
Jun 17, 2008, 3:31:26 AM6/17/08
to Firebug
It took a lot of mucking around, but I finally found the problem. In
my prefs.js, I had javascript.options.strict set to true. Switching
this off fixed (the most major) of my performance problems. (Gmail
load time reduced from 50s to 5s!)

Testing:

- Created a fresh profile, installed Firebug
- Opened "C:\", firebug icon became coloured
- Loaded, then reloaded, Gmail in new tab: 4.73s (by stopwatch,
firebug icon still coloured)
- Opened about:config in new tab, set javascript.options.strict to
true. Closed tab.
- Reloaded Gmail: 51.63s

I'm not sure why I had this pref turned on, since it's not the kind of
thing I'm interested in. All the same, maybe this testcase is
something the Firebug devs could use to tune performance? I'm guessing
it would be a logging-related problem.

Also, it looks like this preference is known to cause problems
( http://dean.edwards.name/weblog/2007/08/firebug-slow/ ), but given
that the console is disabled for Gmail, slowdowns shouldn't be
occurring since nothing is being logged.

John J Barton

unread,
Jun 17, 2008, 11:31:28 AM6/17/08
to Firebug


On Jun 17, 12:31 am, voracity <vorac...@gmail.com> wrote:
> Also, it looks like this preference is known to cause problems
> (http://dean.edwards.name/weblog/2007/08/firebug-slow/), but given
> that the console is disabled for Gmail, slowdowns shouldn't be
> occurring since nothing is being logged.

Gee, I just don't know what to do.

Disabling Firebug for Gmail does not work.

How about that? Does it make the problem clearer?

John.

John J Barton

unread,
Jun 17, 2008, 7:03:49 PM6/17/08
to Firebug
Ok, I am reading this and thinking that it could be mis-interpreted.
Let me start over.

Thanks for reporting this valuable analysis! I want to point one
aspect of your report that is a common misconception. You say "...the
console is disabled for Gmail, slowdowns shouldn't be occuring..."
However this isn't true, to varying degrees depending on the Firebug
version.

The mozilla system for error reporting combines errors from all
sources and send them into one event queue. Once the queue is open,
you can't select which window you get errors from. Setting disabled
for GMail can't stop errors from GMail from being pumped into the
event handler. So when you set javascript.options.strict and use GMail
you will see performance hit. This is why the whole "disable for site"
discussion concerns me: the best we can do is "kinda disabled for
site".

In Firebug 1.2 I've tried to reduce the overhead, but there is only so
much that can be done.

Based on your analysis I am considering adding a message to firebug
warning users when they have javascript.options.strict true. What do
you think?

John

voracity

unread,
Jun 18, 2008, 9:39:46 PM6/18/08
to Firebug
On Jun 18, 9:03 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> The mozilla system for error reporting combines errors from all
> sources and send them into one event queue.  Once the queue is open,
> you can't select which window you get errors from.

Actually, if I open a new window (not tab), the firebug icon goes grey
again and there are no slowdowns in that window. (Which is one of the
workarounds I was using before.) I'm sure you know that, just
clarifying.

>  Setting disabled
> for GMail can't stop errors from GMail from being pumped into the
> event handler. So when you set javascript.options.strict and use GMail
> you will see performance hit. This is why the whole "disable for site"
> discussion concerns me: the best we can do is "kinda disabled for
> site".

Except that the slowdowns don't occur in a fresh profile (sans
Firebug) when javascript.options.strict is enabled, even though the
strict warnings are all still available in the error console. Even if
I have the console open while gmail is loading, while I see all the
strict warnings flashing by, I don't see any slowdowns.

Is this because the error console event handling is written in C++?

> In Firebug 1.2 I've tried to reduce the overhead, but there is only so
> much that can be done.

And I appreciate all the work you've put in. I hope you're not
confusing testing/bug reports/suggestions with ignorant criticism.
(Though I appreciate you have repeatedly told people about the
'Firebug is not really disabled' problem --- and that you may be quite
busy now with the release of Fx3!)

> Based on your analysis I am considering adding a message to firebug
> warning users when they have javascript.options.strict true. What do
> you think?

It would have saved me some frustration, so it would probably be
useful to others as well. OTOH, I should have installed Firebug into a
fresh profile from the very start to discover the cause was somewhere
in my settings.

John J Barton

unread,
Jun 19, 2008, 1:00:27 AM6/19/08
to Firebug


>
> > Based on your analysis I am considering adding a message to firebug
> > warning users when they have javascript.options.strict true. What do
> > you think?
>
> It would have saved me some frustration, so it would probably be
> useful to others as well. OTOH, I should have installed Firebug into a
> fresh profile from the very start to discover the cause was somewhere
> in my settings.

In 1.2b4, Console options will include javascript.options.strict
Reply all
Reply to author
Forward
0 new messages