In the shell, the toplevel calls to JS_ExecuteScript perform 14354 page faults on my (OS X 10.6) machine, at an average cost of about 4us each (have not tested browser or other operating systems). This works out to a cost of ~60ms, most of which I suspect is reflected in the benchmark run time (faults occurring before the start time is computed, like those from compilation of the global script, are not reflected in the run time).

Repeated measurements on a Linux box (dm-sixgill01). This generates a similar number of page faults (13954), but the average cost of a fault is less --- 1.8us each, for a total time of 25ms.

Page fault breakdown for SS: Date: (11 faults) Add: (14 faults) InitElem: (16 faults) NewInitObject: (30 faults) String.charCodeAt: (36 faults) String.split: (45 faults) Array.toString: (48 faults) SlowNew: (49 faults) SetElem: (54 faults) GetGlobalName: (81 faults) ConcatStrings: (360 faults) ConcatN: (397 faults) SetName: (522 faults) JaegerShot: (657 faults) resizeDenseArrayElements.growth: (679 faults) SlowCall: (684 faults) RegExp.test: (938 faults) resizeDenseArrayElements.initial: (975 faults) eval: (1009 faults) String.replace: (2766 faults) NewFinalizableGCThing: (3464 faults) Concentrated in GC objects, array fills, string and regexp operations (no surprise). 1006 of the eval faults are in the string-tagcloud JSON, and will mostly go away when bug 577359 is done.

Brian, is this still worth investigating in the Ion world?

This was never really a problem with JM, but more with the VM itself and (in particular) the lack of generational GC. Still, this bug is old and not worth keeping around.