Hi Colin,
First of all, it's important to understand that a debugger *always*
slows things down (when active of course). This is not specific to
Firebug or even to JavaScript, it's a natural consequence of the
overhead introduced in order for one to be able to better understand
what's happening (debug, that is). Specifically to Firebug, I remember
the curious fact of Gmail notifying [1] users about it and even
providing instructions on how to disable the plug-in [2]. :-)
As a side note, over the years I've even learned to deal/have this in
mind even when using complied code (such as C/C++): as weird as it may
sound, some timing or multi-thread bugs may stop/start reproducing
just because you are running the debugger or simply because you are
using debug builds. :-|
> > > Firefox (firebug open, page freshly loaded)
> > > Request with "evalScripts:true" result is ~233 while Request.JSON
> > > ~1800
Most JavaScript frameworks use 'eval' to turn JSON encoded in a string
(the result of the HTTP request) into a JavaScript object, at least as
some for of fallback. Many recent frameworks (or framework versions)
are already using browser's native JSON when available, and fallback
to the working-but-less-secure-and-slower 'eval' if an older browser
(which hasn't got native JSON) or browser configuration/add-on (which
may have disabled those methods) is being used. That's why when
searching for 'eval' within JSON-related code of even in the most
recent JavaScript framework versions you'll usually end up with some
results, simply the code path which actually executes is usually not
that one. ;-)
Firebug enables you to debug eval scripts ("Decompile for eval()
source" option of "Script" tab), which should then enable Firebug to
monitor those requests with "evalScripts:true" and should make things
in par with the "Request.JSON" ones.
My final guess is that the overhead you are experiencing is just the
result of a neat Firebug feature which is to display HTTP requests
delivered as JSON (this will depend on the MIME type set by your
server) in a structured way when "Show XMLHTTPRequests" (of "Console"
tab) is enabled. If you enable that option, note that JSON responses
have an extra tab which allows "browse" through the request. The net
response is that if/when you aren't really using debugger features
(like the "Net" tab, which introduces a big deal of overhead and the
already stated "Decompile for eval() source" and "Show
XMLHTTPRequests") just disable them: it's a good practice only
introducing something which interferes (in this case, overhead) with
the process if it adds value to it (again, in this case, allows you to
debug something). ;-)
My rule of thumb is: disable Firebug when you aren't developing,
disable all Firebug features I'm not using when developing, and
disable specific Firebug features when I'm not in need of them
(although I can't help myself always leaving the super-cool "Disable
Break On All Errors" feature enabled when Firebug is active, which
already allowed me finding bugs which were *very* hard to
reproduce). :-)
> Colin
Hope this helps,
Helder
[1] http://googlified.com/gmail-firebug-makes-me-slow/
[2] https://mail.google.com/support/bin/answer.py?answer=77355
--
You received this message because you are subscribed to the Google Groups
"Firebug" group.
To post to this group, send email to fire...@googlegroups.com.
To unsubscribe from this group, send email to
firebug+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/firebug?hl=en.
