Open Bug 549543 Opened 15 years ago Updated 4 months ago

Extend eval cache to cache setTimeout programs

Categories

(Core :: JavaScript Engine, enhancement, P5)

enhancement

Tracking

()

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
Keywords: perf
Priority: P1 → P2
Target Milestone: mozilla1.9.3a3 → ---
Assignee: general → nobody
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
QA Whiteboard: qa-not-actionable

(Realistically this needs to be motivated again if we wanted to do this)

Blocks: sm-js-perf
Severity: major → S4
Type: defect → enhancement
Priority: P3 → P5

relevant for JetStream3?

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.