Add an option for the tracer panel

RESOLVED WONTFIX

Status

()

Firefox
Developer Tools: Debugger
P3
normal
RESOLVED WONTFIX
4 years ago
3 years ago

People

(Reporter: vporof, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
If things are in a requestAnimationFrame or a tight interval, you're gonna have a bad time.

Try the tracer on http://lights.elliegoulding.com/
(Reporter)

Comment 1

4 years ago
Created attachment 8347086 [details]
screencast.mp4
Haven't tried on that page yet, but I've been using http://codemirror.net/ and have gone from

* type
* unresponsive for 5 seconds
* beackball for 5 seconds
* text and logs appear

to

* type and text and logs appear but there is some noticeable lagginess but not so much that it is hard to type

And that is with dropping MAX_TRACES from 1000 to 200. I'm sure we can squeeze out a little more performance, but I doubt we are going to see any orders of magnitude. In my profiling (of code mirror being traced), our JS is only taking about 30% of time, 50% of time is taken by the platform when appending the document fragment, and the last 20% was code mirror itself. And of course, putting spidermonkey in debug mode with an empty onEnterFrame hook is about 12x slower than when we are in ion according to Jim's benchmark.

I tried using MAX_TRACES as the maximum amount of traces we will show at any given time, rather than the maximum number of traces we will add at one time so that we could use an object pool for the log elements (IIRC, around 6% of the time I was seeing in our JS code was GC). Unfortunately, removing extra elements that would cause the number of logs to be greater than MAX_TRACES before adding the new logs totally screwed over performance. So that is why we just keep adding logs while the bursts of logs are small, and whenever a burst is  larger than MAX_TRACES, we just empty the logs and then append the most recent MAX_TRACES number of logs.

The good news is that bug 949729 should help cut down on the time spent appending the document fragment, which is what is really killing us.

I could also see moving MAX_TRACES down to 150, but 100 is definitely too low.

I saw you opened a couple bugs for speeding up various things in |_createView| a little as well. Good eyes! I'd love to hear any other thoughts you have.
(Reporter)

Comment 3

4 years ago
(In reply to Nick Fitzgerald [:fitzgen] from comment #2)

In this particular case, the framerate goes from about 60fps to 0.2 (yes, a draw every 3-4 seconds) while using the Tracer. I don't think this is so much about the view being slow, but I may be wrong.

I imagine many web devs will want to trace things going on in tight loops, especially when it comes to animation, so (if possible) we *really* need to do something about this before enabling the Tracer by default. The jank is too damn high :)
(In reply to Victor Porof [:vp] from comment #3)
> do something about this before enabling the Tracer by default. The jank is
> too damn high :)

Its over 9000!
Moved the iteration over traces from the controller to a worker. Not sure this is actually a benefit because 27% of time is now spent in postMessage just sending the data to the worker :-/ Perhaps I can serialize it to an array buffer and then just transfer ownership of the array buffer to the worker and do the same thing on the way back.

Anyways, unlike my profiling on code mirror, the backend is taking up a significant amount of time on Ellie Goulding's site. Because of the ordering of our profiler's tree (top down vs. bottom up), I don't have the total time spent in onEnterFrame, but the following subtree appeared a bunch of times. This is the most expensive one:


* 14.1% - onEnterFrame
** 5.7% - createValueGrip
*** 5.6% - objectDescriptor
**** 2.6% - propertyDescriptor
** 4.8% - getOffsetColumn
Serializing to array buffers and transfering to a worker is slower than just not using a worker. Abandoning the pursuit of workers.

So next I just commented out all the code in |onEnterFrame| so that all it does is return { type: "enteredFrame" }, and the same thing for |onExitFrame|. Then I commented out all the code in DebuggerController.Tracer.onTraces so that it was a completely empty function and the frontend wasn't doing anything. Now all the tracer was doing was creating a near empty object for each call/return, and sending them across the protocol every 50ms.

I was only able to get about three or four frames per second on the Ellie Goulding site.

Let me rephrase for effect: commenting out most of the tracer code, to the point it isn't doing anything remotely close to useful, we incur a horrible horrible performance overhead when tracing the Ellie Goulding site. There is no way we are going to get anywhere near a smooth experience when we have to record this many calls/returns.

So. Do we continue development with the tracer and accept that it won't be performant on sites like the Ellie Goulding one? Or do we cut our losses and move on?
I believe we should continue to work on the tracer, improving performance and the UI as much as possible. A tracer is a uniquely useful tool in many cases, even in its current state. Tracing animation-heavy or WebGL-heavy sites may not be working adequately right now, but I was able to trace google.com and GMail for crying out loud! There is a broad range of applications that can benefit from it and we shouldn't deprive our users from such a tool IMO.

I'm confident that we will be able to identify potential areas for performance improvement in the future, either in the debugger server or in SpiderMonkey. Maybe even bug 716647 can be an improvement.
(Reporter)

Comment 8

4 years ago
Not shipping the Tracer is out of the question :) There's simply too much good work here to throw away.

The Tracer not being useful for a certain percentage of all possible use-cases is not a good argument for completely amputating this functionality. If it's beneficial for a non-negligible percentage of users, it should be available.

We just need to be very careful about how we're marketing this, making sure the developers *know* their content will slow down, in some cases significantly, while not even noticeably in others. The most aggressive way of doing this is having a Tracer entry in an "experimental" section in the Options panel, clearly specifying the performance implications of using it while enabled.

It might be possible alleviate the perf situation on animation/loop heavy websites in a few ways, like replacing the backend with Rik's implementation (or something similar), which instruments the js code, instead of having all those frame hooks like we do now. Another thing we could do is investigate why those hooks are slow, and fix that!
I agree. It would be a shame to not ship this because it doesn't work on certain classes of applications. Discussing it with Nick, it would be good to pref this off initially and provide an Experiemental section to our Options panel. Could do that here or in a follow-up.

shipit!
Summary: Tracing is incredibly slow on pages with moderate JS → Add an "experimental"
Summary: Add an "experimental" → Add an "experimental" section to the options panel and place the tracer in it
No longer blocks: 929349
Depends on: 929349
Priority: -- → P3

Updated

4 years ago
Blocks: 1071521

Updated

4 years ago
Summary: Add an "experimental" section to the options panel and place the tracer in it → Add an option for the tracer panel
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.