On 04/12/2017 06:55 AM, Kannan Vijayan wrote:
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.
What do you mean by skew? You mean the time will be shifted between when it happens and when it is recorded? I was assuming these would be recorded with profiler markers, which have a timestamp in them that AFAIU can be postdated. But later you use skew to refer to bias in the sampling due to profiler-related overhead, which I agree is a real issue.
I agree that the granularity seems too fine, especially if it's for something like "every time a generic stub runs". Maybe just sample the cumulative counts of various things? With postprocessing, that could be converted into an estimated number of events per millisecond of JS execution or something. The goal would be something like: you have a profile that shows a big chunk of time in JS, and you want to know whether it was "fast JS" (in which case the only way to improve would be to run less or do less) or "slow JS" (in which case optimizing the JS code or the JIT engine might be worthwhile.) It would not be a definitive answer either way, but at least it might point in a useful direction to investigate.
But yeah, the profiler usage scenario is somewhat different from the telemetry one.
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.
I like to distinguish sampling from tracing, since the profiler does both. (It samples call stacks, including pseudoframes and JS; it traces via markers, which get emitted unconditionally.) The core overhead of traversing data structures when sampling generally isn't too bad, but maintaining those data structures can be. The overhead of tracing, on the other hand, is proportional to how much stuff is happening. So it can easily get really bad, and it biases your sampling. I believe the latter is what you're referring to?
On Wed, Apr 12, 2017 at 9:38 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com <mailto:ehsan.akhg...@gmail.com>> wrote:On 2017-04-12 5:33 AM, Jan de Mooij wrote: > On Tue, Apr 11, 2017 at 11:25 PM, Steve Fink <sf...@mozilla.com <mailto:sf...@mozilla.com>> wrote: > >> The juxtaposition of telemetry and the IC logger makes me wonder -- is it, >> or could it be, lightweight enough to report on via telemetry? It would be >> 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 clear > how actionable this data would be (the IC logger stores additional > information about the IC inputs) but it might reveal something interesting > 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 dev-tech-js-engine-internals@lists.mozilla.org <mailto:dev-tech-js-engine-internals@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals <https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals>
_______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
