Bug 652377 (crockmark)

Opportunities to speed up crockmark

NEW
Unassigned

Status

()

defect
8 years ago
5 years ago

People

(Reporter: luke, Unassigned)

Tracking

(Depends on 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

234.32 KB, application/x-javascript
Details
(Reporter)

Description

8 years ago
Posted file shell benchmark
Douglas Crockford had an interesting post:
  http://crockford.com/javascript/performance.html
He timed (though with an unspecified method) JSLint running on jslint.js and found that IE was the fastest, JM was second (70% slower), and Chrome 5x worse.

I attached a jslint.js shell testcase that snarfs and runs JSLINT on itself.  My months-old d8 is indeed 3x slower than us (wasn't able to try IE, and my old jsc build crashed).  Sharking 'js -m -j -p attachment.js' gives the following breakdown:

31.0% in mjit code
 2.6% in regex jit code
12.1% creating regex return object
 5.5% kernel time  (mostly vm faults near regexp object creation)
20.1% under prop/name mjit stubs
   7.0% under stubs::GetProp
   4.2% under stubs::GetElem
   4.2% under stubs::CallName
   2.6% under stubs::SetName
   1.3% under stubs::BindElem
   0.8% under stubs::SetElem
 4.6% stubs involving string manipulation
   2.3% under stubs::StrictEq (js::EqualStrings)
   0.9% under stubs::StrictNe (js::EqualStrings)
   0.6% under stubs::Add (js_ConcatStrings)
   0.8% under stubs::LookupSwitch (js::EqualStrings)
 3.4% under stubs::CreateFunCallObject
 1.5% under obj_create
 0.9% stubs::FixupArity

A few notes on this:

JSLINT does a lot of regexp exec().  Our exec()-return-object creation is already known to be really slow.  Bug 586842 would let us build a dense array for the result instead of slow array.  Also, we should be able to make js_DefineProperties faster than just calling js_DefineProperty in a loop, or just make a fast path specialized for regexp.exec; js_DefineProperty is, relatively, a *really* slow path.

Generational GC should help on all that kernel time (collect regexp.exec garbage, stay in cache).  Even better (perhaps built with IonMonkey infrastructure) the seemginly one focal place where regexp.exec is called would be highly amenable to linearity inference would would let us eagerly free objects.

I don't know much about the property access stubs, but it seems Crockford really likes to use Object.create which may be producing new shapes each time?

There have also been plans for mjit fast paths for strings and call obj creation.

Lastly bug 648698 would make the FixupArity go away.

Altogether, these sources of slow-down would account for ~45% of our time and, if they were all magically fixed, would put us at or better than IE.
Bug 827490 just landed.  It might help here.
Alias: crockmark
Summary: opportunities to speed up crockmark → Opportunities to speed up crockmark

Comment 2

6 years ago
According to AWFY, this benchmark regressed more than 30% since June.
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.