Closed Bug 389347 Opened 17 years ago Closed 7 years ago

XPCTools JS profiler reports getters/setters as anonymous functions

Categories

(Core :: XPConnect, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: myk, Unassigned)

References

Details

In a recent profile of the startup process (bug 385224, attachment 273289 [details]), the XPCTools JavaScript profiler reported getters as "anonymous" functions. Although it's possible to figure out which anonymous function is which getter by looking up the line numbers provided, it'd be a lot easier to work with the results if the profiler identified these getters by the name of the property they get. Presumably setters have the same problem (and solution), although I didn't actually find any of those when I looked up a pseudo-random sample of the functions listed as anonymous. Icing: I did note a function defined as a property of property thusly: function SomeObject() {} SomeObject: { doFoo: function() {} } Ideally, it would be great if the profiler knew how to assign names to these functions as well, although in this case I can fix the problem by assigning the function a name.
BTW, rginda was big on giving function expressions names for debubing purposes, but I wanted to note that this slows down invocation of such lambda expressions, because an Object instance must be created and the function name bound as a variable referring to the callee, as the scope parent of the function activation. This is unwanted overhead that's hard to optimize away without violating ECMA-262 Edition 3. So my advice is not to add unnecessary lambda names. This bug should be fixable using bytecode inspection under the JS debugger API. /be
Blocks: 389368
(In reply to comment #1) > BTW, rginda was big on giving function expressions names for debubing purposes, > but I wanted to note that this slows down invocation of such lambda > expressions, because an Object instance must be created and the function name > bound as a variable referring to the callee, as the scope parent of the > function activation. This is unwanted overhead that's hard to optimize away > without violating ECMA-262 Edition 3. Not to mention the naming duplication and the difficulty of fitting the declaration into 80 characters, leading to long lines, cumbersome wrapping schemes, or suboptimally shorter function names (of course these consequences are not always avoidable, f.e. when the functions have long parameter lists). > So my advice is not to add unnecessary lambda names. This bug should be fixable > using bytecode inspection under the JS debugger API. Sounds good to me. I have filed bug 389368 on removing the names once this bug gets fixed.
If there's a performance win here from removing the names, then it would be great to get this for 1.9, where we can use all the performance wins we can get.
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9-
Bug 433529 should make this possible (see also bug 805222), but I don't know whether this tool is still used/maintained.
XPCTools doesn't exist any more, AFAICT.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.