It's possible to expose in the profiler UI, although the granularity might
be too high and skew might be an issue. Really this is more of a
telemetry-style metric - we can accumulate counts for how often fallbacks
are hit (or how often we generalize into a polymorphic stub) and report
that as a single number or set of numbers per script on a periodic basis.
That said, it might still be useful even with the skew. It's just that as
we keep adding more and more stuff to "sample" in the profiler, we risk
death-by-a-thousand-skews in being able to interpret the results. We have
enough problems with that as it is in other areas.
On Wed, Apr 12, 2017 at 9:38 AM, Ehsan Akhgari
> On 2017-04-12 5:33 AM, Jan de Mooij wrote:
> > On Tue, Apr 11, 2017 at 11:25 PM, Steve Fink wrote:
> >> The juxtaposition of telemetry and the IC logger makes me wonder -- is
> >> or could it be, lightweight enough to report on via telemetry? It would
> >> pretty cool to be able to drive work off of what the bulk of our users
> >> could make use of.
> > We could for example record - for each IC kind - how often we managed to
> > attach a stub (this should approach 100%) or how many ICs were marked as
> > 'Generic' (= we gave up on optimizing for some reason). It's not very
> > how actionable this data would be (the IC logger stores additional
> > information about the IC inputs) but it might reveal something
> > or catch regressions. There are also other JIT things we could add
> > telemetry for, for instance IonBuilder abort reasons. It's definitely
> > something to think about.
> Is any of this something that can be exposed in the profiler UI somehow
> so that people like me who sometimes file bugs providing a profile of
> something being slow on a website can provide an IC log or some such?
> dev-tech-js-engine-internals mailing list