Open
Bug 549543
Opened 15 years ago
Updated 4 months ago
Extend eval cache to cache setTimeout programs
Categories
(Core :: JavaScript Engine, enhancement, P5)
Core
JavaScript Engine
Tracking
()
NEW
People
(Reporter: brendan, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf)
From a shark sample on my 100%-cpu-consuming Namoroka:
2.9% 2.9% libmozjs.dylib JS_DHashTableEnumerate
0.0% 2.7% libmozjs.dylib js_PurgeScriptFragments(JSContext*, JSScript*)
0.0% 2.7% libmozjs.dylib js_DestroyScript
0.0% 2.7% libmozjs.dylib JS_EvaluateUCScriptForPrincipals
0.0% 2.7% XUL nsJSContext::EvaluateString(nsAString_internal const&, void*, nsIPrincipal*, char const*, unsigned int, unsigned int, nsAString_internal*, int*)
0.0% 2.7% XUL nsGlobalWindow::RunTimeout(nsTimeout*)
0.0% 2.7% XUL nsGlobalWindow::TimerCallback(nsITimer*, void*)
0.0% 2.7% XUL nsTimerImpl::Fire()
This needs some dedicated API, since we do not want to blow out the cache due to any and all JS_Evaluate*Script* API calls, only ones for programs likely to be repeatedly compiled and executed (setTimeout, setInterval with string first arg).
Who will take this bug? It is crying for a fix.
/be
Updated•11 years ago
|
Priority: P1 → P2
Target Milestone: mozilla1.9.3a3 → ---
Assignee | ||
Updated•11 years ago
|
Assignee: general → nobody
Comment 1•7 years ago
|
||
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Comment 2•4 years ago
|
||
(Realistically this needs to be motivated again if we wanted to do this)
Comment 3•4 months ago
|
||
relevant for JetStream3?
Comment 4•4 months ago
|
||
As I understand it, this is about setTimeout("some string")
and setInterval("some string")
, both of which MDN marks as "not recommended". I don't think this specific problem shows up in JetStream.
That said, it looks to me like it is still a potential problem. If I'm tracing through the DOM code correctly, both setTimeout and setInterval bottom out here (window) and here (worker), and AFAICT neither case ends up looking at the eval cache.
As Matt says, though, I think we'd need to see a real-world example where this is hot to fix it now.
You need to log in
before you can comment on or make changes to this bug.
Description
•