266514 - Tp hit from ClassInfo for nsConsoleService

Status: RESOLVED WONTFIX

(Core :: XPConnect, defect)

Description

[timeless]

attachment 155795 [details] [diff] [review] (patch for bug 254555) marked nsConsoleService as THREADSAFE
(and also SINGLETON per dougt). We believe this caused a perf hit (Tp ~8s).

ClassInfo is necessary, so we need to work on improving its performance /
reducing the performance hit.

My guess is that by implementing nsIClassInfo, xpconnect ends up doing extra
work to check classinfo flags on the consoleservice each time it's hit.

i could be wrong :(.

Comment 1

[Johnny Stenback (:jst)]

Hmm, seems like it'd be cool to not need to worry about XPConnect's performance
here in the case where the JS console isn't even open. We shouldn't have any JS
listeners in that case, but apparently we do. Anyone know why?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Do we?  I don't see other places where registerListener() is called, other than
the JS console's init() method.

May be worth putting a breakpoint in registerListener() and seeing whether it's hit.

Could the classinfo change possibly affect calls to the console service from C++
code?  I'd guess no, but...

It's also possible (though very unlikely) that the performance regression was
due to bug 265336 instead.

Comment 3

[Johnny Stenback (:jst)]

(In reply to comment #2)
> Could the classinfo change possibly affect calls to the console service from C++
> code?  I'd guess no, but...

I'd guess no too...

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

We're not going to isolate and fix a perf regression from 6 years ago.