1134249 - Add fake frames for when code triggers the collapse of a rope string

Status: RESOLVED DUPLICATE of bug 1074935

(DevTools :: Performance Tools (Profiler/Timeline), defect)

Description

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

So we are adding fake frames for JIT optimization info. Could we do something similar for when some JS code triggers the collapse of a rope into a linear string?

I had some code that was sped up a bunch by keeping the same string around and explicitly managing the current index rather than calling slice willy nilly. I *think* what was happening was that I was doing something that accidentally caused a flattening into a linear string, but I'm not 100% sure.

It would be awesome if we had some tooling for exposing when/where these kinds of potentially expensive operations are triggered.

Comment 1

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Shu mentioned on IRC that we could potentially just recognize the C++ frame, rename it to something web devs understand, and not hide it when we filter out platform data.

Comment 2

[Shu-yu Guo [:shu]]

(In reply to Nick Fitzgerald [:fitzgen] from comment #0)
> So we are adding fake frames for JIT optimization info. Could we do
> something similar for when some JS code triggers the collapse of a rope into
> a linear string?

To clarify, the interface we decided on does not add fake frames for perf info. Instead, each real frame has optional optimization info attached.

Luke's original idea was that the leaf frames (i.e., the youngest frames) would have fake frame-like entries under them that contained the perf info. But this doesn't generalize well, since non-youngest frames may also have perf info: inlining success/failures, and why.

Comment 3

[Jordan Santell [:jsantell] [@jsantell]]

Would this work alongside bug 1108843? Is this similar to jit coach concept, where we highlight potentially expensive frames based off of some heuristics?

Comment 4

[Kannan Vijayan [:djvj]]

I don't think so.  Meta category nodes are in fact, very close to a "fake frame" concept.  This here is notionally an annotation on an existing frame (i.e. the frame where the rope linearization happens).

In fact, there are other events which naturally exhibit as annotations of an existing frame:

Exception thrown in a frame.
Bailout from Ion => Baseline in a frame.
Invalidation in a frame.

This seems like one of those events where the frame's code itself is annotated as having had this happen (maybe along with some site information like bytecode offset).