Walking Components.stack is slow

NEW
Unassigned

Status

()

defect
7 years ago
Last year

People

(Reporter: msucan, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

For the window.console API implementation (dom/base/ConsoleAPI.js) we have to walk the Components.stack frames, from caller to caller to find the frames that are in JS and build an array.

We use Components.stack for every window.console API call to be able to show a stack trace in the Web Console for each logged message.

While working on fixing bug 746869 we've found that walking Components.stack is quite slow. We'd appreciate some performance improvements.

Thanks!
The basic problem is that the nsIStackFrames and whatnot are using full-on XPConnect wrappers... and are REALLY SLOW (tm).

There's the JS-wrapping being slow, the lookup of the methods, the security checks, etc etc.

Oh, and the methods don't live on the proto, so for each stackframe we define it on the object.

I wonder whether we could move stackframes to some saner setup.  Somehow.
A simple measure might be to define nsIClassInfo, which would let the methods live on the proto. Is that known to be faster?
Well, my profile shows 20% of the time is DefinePropertyIfFound, iirc.

Simply trying out classinfo should tell us whether things got 205 faster....
You need to log in before you can comment on or make changes to this bug.