Changes between Initial Version and Version 1 of Ticket #3708, comment 27
- Timestamp:
- Aug 25, 2016, 9:21:37 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #3708, comment 27
initial v1 4 4 5 5 I've asked h4writer on the #jsapi channel today. Reduce.py ignores the data for everything that's shorter than a certain threshold. This threshold goes up the more data you collect, which means it's very high in our case. This causes compilation events to be ignored and explains why the count can be 0 even though it runs in ion mode. Much worse is the fact that this also applies to the number for total runtime per function. Functions with a high runtime per call show a higher runtime than functions which run the same time in total but are called more often and take less time per call. 6 Reduce.py writes a special corrections file by default to fix th is issue, but there was a bug and the tracelogger didn't actually use these corrections to display the data. This is now fixed an the data really looks a lot different and much more plausible. Instead of > 10%, Timer.js:67 now only takes 2.84%.6 Reduce.py writes a special corrections file by default to fix these issues, but there was a bug and the tracelogger didn't actually use these corrections to display the data. This is now fixed an the data really looks a lot different and much more plausible. Instead of > 10%, Timer.js:67 now only takes 2.84%. 7 7 8 8 Internal time is still around 30%, which seems quite a lot to me, but he said that's possible. The tracelogger now doesn't include this internal time in the total time of functions anymore, which is much more intuitive. Before this change, there was a function that took around 8% total time but spent more than 99% flushing tracelogger data (so it wasn't expensive at all but just "unlucky" that flushing happened during the runtime of that function).
