XPCTools JS profiler reports getters/setters as anonymous functions

RESOLVED WONTFIX

Status

()

Core
XPConnect
--
enhancement
RESOLVED WONTFIX
11 years ago
2 months ago

People

(Reporter: myk, Unassigned)

Tracking

unspecified
Points:
---
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
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
(Reporter)

Updated

11 years ago
Blocks: 389368
(Reporter)

Comment 2

11 years ago
(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.
(Reporter)

Comment 3

10 years ago
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
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.