Open Bug 549543 Opened 14 years ago Updated 2 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.