Bugzilla

Information on the hit rates.

For awsy (tp-6), the overall hit rate is 72.4%. Most of the misses are unavoidable. Of the theoretically possible inputs, the hit rate is 99.0%. Well, unless you magically analyzed the replacer function for side effects or something, or observed everything you cared about while it was running. If you count the replacer function as a miss, then the hit rate is 91.8%.

Of all calls that took the slow path:

  - 20.8% had a replacer function and so were ineligible
  - 76.4% were primitives
  - 0.1% were ineligible for other reasons
  - 2.1% found an object with a callable toJSON function
  - 0.7% bailed for other reasons (sparse indexes was the most common)

For just speedometer3 (plus some startup noise):

  - overall hit rate is 84.6%
  - hit rate only counting non-primitives that aren't going to run any code is 98.7%
  - hit rate for all non-primitives is 97.1%

Of all calls that took the slow path:

  - 8.4% had a replacer argument
  - 83.5% were primitives
  - 0.7% found something with a callable toJSON property
  - 7.4% found an INELIGIBLE_OBJECT, which could be a variety of things. Typed arrays, BigInts, non-native objects, etc.

That last category is the only category that could be reasonable to reduce right now, but the effort doesn't seem worth it just for bumping the hit rate by a percentage point or so.

A magical analysis that could tell whether a given function could possibly have any side effects on the data in question could boost the hit rate by a lot more, but that would only make sense if we were doing it for something else too.

Information on the hit rates.

For awsy (tp-6), the overall hit rate is 72.4%. Most of the misses are unavoidable. Of the inputs where it is theoretically possible to use the fast path, the hit rate is 99.0%. Well, unless you magically analyzed the replacer function for side effects or something, or observed everything you cared about while it was running. If you count the replacer function argument as a miss, then the hit rate is 91.8%.

Of all calls that took the slow path:

  - 20.8% had a replacer function and so were ineligible
  - 76.4% were primitives
  - 0.1% were ineligible for other reasons
  - 2.1% found an object with a callable toJSON function
  - 0.7% bailed for other reasons (sparse indexes was the most common)

For just speedometer3 (plus some startup noise):

  - overall hit rate is 84.6%
  - hit rate only counting non-primitives that aren't going to run any code is 98.7%
  - hit rate for all non-primitives is 97.1%

Of all calls that took the slow path:

  - 8.4% had a replacer argument
  - 83.5% were primitives
  - 0.7% found something with a callable toJSON property
  - 7.4% found an INELIGIBLE_OBJECT, which could be a variety of things. Typed arrays, BigInts, non-native objects, etc.

That last category is the only category that could be reasonable to reduce right now, but the effort doesn't seem worth it just for bumping the hit rate by a percentage point or so.

A magical analysis that could tell whether a given function could possibly have any side effects on the data in question could boost the hit rate more, but that would only make sense if we were doing it for something else and could just reuse it here.