Open Bug 549543 Opened 15 years ago Updated 3 years 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: jsperf
Severity: major → S4
Type: defect → enhancement
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.