Recently I have been having issues with Firefox 3 on Ubuntu Hardy Heron.
I will click on a link and it will hang for a while. I don't know if its a bug in Firefox 3 or a page running too much client side JavaScript, but I would like to try and debug it a bit.
So, my question is "is there a way to have some kind of process explorer, or task manager sort of thing for Firefox 3?"
I would like to be able to see what tabs are using what percent of my processor via the JavaScript on that page (or anything in the page that is causing CPU/memory usage).
Does anybody know of a plugin that does this, or something similar? Has anyone else done this kind of inspection another way?
I know about FireBug, but I can't imagine how I would use it to finger which tab is using a lot of resources.
Any suggestions or insights?
It's probably the awesome firefox3 fsync "bug", which is a giant pile of fail.
In summary
Firefox3 saves its bookmarks and history in an SQLite database
Every time you load a page it writes to this database several times
SQLite cares deeply that you don't lose your bookmarks, so each time it writes, instructs the kernel to flush it's database file to disk and ensure that it's fully written
Many variants of linux, when told to flush like that, flush EVERY FILE. This may take up to a minute or more if you have background tasks doing any kind of disk intensive stuff.
The kernel makes firefox wait while this flush happens, which locks up the UI.
So, my question is, is there a way to have some kind of process explorer, or task manager sort of thing for Firefox 3?
Because of the way Firefox is built this is not possible at the moment. But the new Internet Explorer 8 Beta 2 and the just announced Google Chrome browser are heading in that direction, so I suppose Firefox will be heading there too.
Here is a post ( Google Chrome Process Manager ),by John Resig from Mozilla and jQuery fame on the subject.
There's a thorough discussion of this that explains all of the fsync related problems that affected pre-3.0 versions of FF. In general, I have not seen the behaviour since then either, and really it shouldn't be a problem at all if your system isn't also doing IO intensive tasks. Firebug/Venkman make for nice debuggers, but they would be painful for figuring out these kinds of problems for someone else's code, IMO.
I also wish that there was an easy way to look at CPU utilization in Firefox by tab, though, as I often find myself with FF eating 100% CPU, but no clue which part is causing the problem.
XUL Profiler is an awesome extension that can point out extensions and client side JS gone bananas CPU-wise. It does not work on a per-tab basis, but per-script (or so). You can normally relate those .js scripts to your tabs or extensions by hand.
It is also worth mentioning that Google Chrome has built-in a really good task manager that gives memory and CPU usage per tab, extension and plugin.
[XUL Profiler] is a Javascript profiler. It
shows elapsed time in each method as a
graph, as well as browser canvas zones
redraws to help track down consuming
CPU chunks of code.
Traces all JS calls and paint events
in XUL and pages context. Builds an
animation showing dynamically the
canvas zones being redrawn.
As of FF 3.6.10 it is not up to date in that it is not marked as compatible anymore. But it still works and you can override the incompatibility with the equally awesome MR Tech Toolkit extension.
There's no "process explorer" kind of tool for Firefox; but there's https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Venkman with profiling mode, which you could use to see the time spent by chrome (meaning non-content, that is not web-page) scripts.
From what I've read about it, DTrace might also be useful for this sort of thing, but it requires creating a custom build and possibly adding additional probes to the source. I haven't played with it myself yet.
Related
I have an ASP.NET MVC application that makes pretty heavy use of javascript and JQuery for both administrative functions as well as customer-facing functions. Recently I reorganized the administrative screens to be able to more cleanly fit administrative controls for some new features.
I tested using IE and Chrome and found that there was a slight, but acceptable hang in one of the busier pages. However, the main person who uses the admin pages uses Firefox and kept reporting an unacceptable hang. I finally checked it out and found that what hangs in Chrome and IE for 2-3 seconds hangs in Firefox for 10-12 seconds, which is no good.
Not knowing where to turn, I wound up installing Glimpse and got it configured and running just fine, but I'm still having trouble figuring out how to drill into it to find out what area of the page is causing trouble. All I can tell so far is that it is definitely something with how the client (Firefox) is rendering. To be clear, it happens on all browsers, but for some reason it is way more pronounced in Firefox.
Can someone please give me some pointers on how to get started on diagnosing the issue? I'm not married to the idea of using Glimpse, but it seems like a pretty decent tool from what I can tell.
Thanks for your help.
Based on what you're describing, the problem appears to be client side. With that said, Glimpse may not be as well-suited as using Firefox's own profiler.
SHIFT+F5 will bring up the web developer performance screen. From there, you can begin/end a performance analysis and gain more insight into what may be taking longer than expected.
It may also be worthwhile to look at the network tab and make sure assets are loading in a timely manner.
Keep in mind as well that add-ins could play into the latency. If the end-user has a setup that performs post-page processing (such as Greasemonkey scripts or (recalling an earlier add-in) a Skype plugin that used to transform phone numbers on the page to direct-dial links), that would also play a part in the performance. A good way to rule these out is to hold down SHIFT while starting up Firefox (effectively running it in Safe Mode), which would determine if it's Firefox itself or an add-in that's to blame.
The Problem
I'm working on a web application where users can sequence audio samples and optionally apply effects to the musical patterns they create using the Web Audio API. The patterns are stored as JSON data, and I'd like to do some analysis of the rendered audio of each pattern server-side. This leaves me with two options, as far as I can see:
Run my own rendering code server-side, trying to make it as faithful as possible to the in-browser rendering. Maybe I could even pull out the Web Audio code from the Chromium project and modify that, but this seems like potentially a lot of work.
Do the rendering client-side, hopefully faster-than-realtime, and then send the rendered audio to the server. This is ideal (and DRY), because there's only one engine being used for pattern rendering.
The Possible Solution
This question lead me to this code sample in the Chromium repository, which seems to indicate that offline processing is a possibility. The trick seems to be constructing a webkitAudioContext with some arguments (usually, a zero-argument constructor is used). The following are my guesses at what the parameters mean:
new webkitAudioContext(2, // channels
10 * 44100, // length in samples
44100); // sample rate
I adapted the sample slightly, and tested it in Chrome 23.0.1271.91 on Windows, Mac, and Linux. Here's the live example, and the results (open up the Dev Tools Javascript Console to see what's happening):
Mac - It Works!!
Windows - FAIL - SYNTAX_ERR: DOM Exception 12
Linux - FAIL - SYNTAX_ERR: DOM Exception 12
The webkitAudioContext constructor I described above causes the exception on Windows and Linux.
My Question
Offline rendering would be perfect for what I'm trying to do, but I can't find documentation anywhere, and support is less-than-ideal. Does anyone have more information about this? Should I be expecting support for this in Windows and/or Linux soon, or should I be expecting support to disappear soon on Mac?
I did some research on this a few months back, and there is a startRendering function on the audioContext, but I was told by Google people that the implementation was, at that time, due to change. I don't think this has happened yet, and it's still not a part of the official documentation, so I'd be careful building an app that depends on it.
The current implementation doesn't render any faster than realtime either (maybe slightly in very light applications), and sometimes even slower than realtime.
Your best bet is hitting the trenches and implement Web Audio server-side if you need non-realtime rendering. If you could live with realtime rendering there's a project at https://github.com/mattdiamond/Recorderjs which might be of interest.
Please note that I'm not a googler myself, and what I was told was not a promise in any way.
Some code in my page is making my browser slow after 20-30 min. I need to know which one. What tools can i use to debug this out.
Following js files are being loaded
Jquery
Jquery ui
History
Mustache
Yes i had settimeout and thought that to be the culprit but alas after removing it too, it's still a bit slow.
You should use Google's Speed Tracer. It's a Chrome extension.
Speed Tracer is a tool to help you identify and fix performance
problems in your web applications. It visualizes metrics that are
taken from low level instrumentation points inside of the browser and
analyzes them as your application runs. Speed Tracer is available as a
Chrome extension and works on all platforms where extensions are
currently supported (Windows and Linux).
Alternatively, you have Yahoo!'s YUI 2: Profiler.
The YUI Profiler is a simple, non-visual code profiler for JavaScript.
Unlike most code profilers, this one allows you to specify exactly
what parts of your application to profile. You can also
programmatically retrieve profiling information as the application is
running, allowing you to create performance tests YUI Test or other
unit testing frameworks.
An addendum to #Julio Santos ' answer
You can use Dynatrace Ajax which has a good free version of their product
So tried my hand at profiling some code and I figured the easiest way to do it (at least on Firefox) was to use either console's time/timeEnd or profile/profileEnd, and I tried both.
The problem I have is with the number of runs I can do before Firefox crashes on me. Now I won't paste the code here because it's typical benchmarking code (and it's very messy), but obviously the gist of it is that it runs functions (a test is represented with a function), logging their execution time for a certain number of runs.
Now with for example, 5e4 it sorta works but I don't think it's enough to spot (very) micro optimizations, but more than that, it crashes.
So how do you profile your JavaScript? Because this way, it's barely feasible.
When I used to profile my JavaScript code I used Chrome's profiler; the JavaScript Console in the developer view gives it, and it pretty much worked for me. Have you ever tried it?
I have tried profiling a page with a lot of scripting in Firebug on FF4 and the same in Chrome (last version). Firefox crashed within a second or two, Chrome didn't seem to have problems with it. Maybe you can find something on it in the Firebug issues list?
Although not a traditional code profiler, I recommend Google's Speed Tracer:
Using Speed Tracer you are able to get a better picture of where time is being spent in your application. This includes problems caused by JavaScript parsing and execution, layout, CSS style recalculation and selector matching, DOM event handling, network resource loading, timer fires, XMLHttpRequest callbacks, painting, and more.
I think the profiler in the JavaScript Debugger (aka Venkman) is quite good. The version currently on addons.mozilla.org is not compatible with Firefox 4, but the change necessary to make it work has been committed. See https://bugzilla.mozilla.org/show_bug.cgi?id=614557 for details.
dynaTrace AJAX edition(free)- one more tool in your bag. Offers a little bit more detailed performance metrics, IMHO. They used to have it only for IE, but their new one supports FF too. Also see Steve Sounder's blog
I'm developing a fairly large page with several external javascript files. In IE6, the page hangs for a few seconds just as it's finished loading. I'm not (directly) asking for help debugging this problem, I'm only asking for help finding a tool to help debug this problem.
What I'm looking for is something similar to Chrome Developer Tools's "Timeline" tab. Something that will tell me the run time of my various external scripts (or functions, event handlers, whatever level of granularity is available).
I'd much prefer something that is free, but if that isn't available, I may be convinced to shell out some cash for a little extra quality.
Please keep in mind that I'm looking for tools that will work with Internet Explorer 6.
I think Dynatrace could be what you're looking for.
It's quite complex but integrates well with IE and gives you more data than you could ever use: Number of times functions get called, CPU usage per function, a step-by-step look at the DOM tree being built... It's pretty intense.
Godspeed.
Fiddler2 will work well for tracking all aspects of the load time... unfortunately no pretty timeline chart though.