-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Event recording & summarize need cleanup with respect to self-time vs incr-load-time vs blocked-time vs total-time. #75
Comments
My suggested answers to these questions are:
Yes. Self-time is what one sorts for when trying to find out what is expensive. It would be unhelpful if something got sorted to the back even though 50% of total compile time is spent loading things for it from the cache.
Let's go with no. That causes fewer events to be generated. Also, in order to make things really uniform, in-memory cache hit events would have to wrapped with a query-provider event too, which would be lots of overhead for not much gain.
Down the line, yes. It's a useful distinction to make. These should all be separate query kinds (incr. cache loading already is). However, I think this is something to be implemented after we have query keys, so we don't make too many changes at once.
Blocking should add to self-time for the same reason as incr. cache loading should add to self-time (see above). I don't remember what I meant by "How about total-time?", I think the question is not relevant anymore since we switched to @andjo403's approach of computing total time as
I haven't thought about this one yet. |
It turns out the natural way of implementing this is that a cache-hit event is indeed generated after each query-blocked event. So this does not behave differently than the regular case. |
At the moment, we have not specified how self-time and other kinds of measurements interact with each other:
The text was updated successfully, but these errors were encountered: