Bug 21172 – Profiler has a significant impact on performance

• Status: RESOLVED
• Resolution: INVALID
• Component: Web Inspector (Deprecated)

[Oliver Hunt]

If you run my 100% real world webpage with the profiler enabled you can see the JS Profiler has a huge (~2x slower) performance impact.  This makes me sad.

To reproduce
1. Click the "render" link and wait for the render to complete
2. Click the "render with profiler" link and once again wait for the render to complete
3. notice that the second time is ~2x larger than the first

Note: this should be done with a new window, and no other windows open.  The inspector should not have been opened as that will trigger excessive GC cost due to the DOM, which is a completely separate issue.

[Mark Rowe (bdash)]

<rdar://problem/6252644>

[Oliver Hunt]

Okay, i'm looking at this and i believe the problem is that the profiler does far too much work on entry/exit.  Requesting the name of a Function is a generic property lookup, and hence is a far too heavy cost for function entry and exit.  I think a better approach would be just to store the function pointer, and retrieve the actual information once profiling is complete.

[Kevin McCullough]

Can you guarantee the function pointer will be valid after profiling is complete?  Will GC collect stuff?  WIll context be lost?

Also is it so bad to slow down while profiling?  As long as profiling doesn't affect the relative speeds of the parts of the code being profiled the numbers will be accurate.

We of course should want JS executing as fast as possible even with the profiler running, so if you have a good solution we should jump on it.

If we can get names after the fact, we need something unique to store in ProfileGenerator that we can compare to see if the same function was called multiple times and then when StopProfiling is called we would convert all of those unique things to strings when storing them in the actual Profile.

Maybe these unique things can simply be stored in the CallIdentifier?

[Oliver Hunt]

Because all of the overhead of the inspector happens on call entry and return the profiler will greatly exaggerate the runtime cost of call heavy code.

To be able to store just the function object pointer you'll need to be add logic so that we can gc any objects that the profile references (i imagine once profileEnd() occurs you can immediately actually extract all the profile info, and drop the funciton object references, but you'll probably want to wait until there are no active profiles)

[Kevin McCullough]

I talked with Geoff a little and he had some good ideas here.  He said we should shoot for the profiler costing 10% overhead.

He also agreed with the idea of holing the JSFunction pointers while collecting the profile and figuring out the names after the fact.  We don't even need to see if there are function duplicates we could collapse them when the profile stops.

Basically he supported the idea of doing as little work as possible during the collection phase; however this does mean we will need to let the Garbage Collector know which functions we are holding onto so that they don't disappear on us!

[Brian Burg]

Closing this in preference for integrating DFG/FTL performance data directly, rather than making the unrealistic interpreter times slightly more realistic.