Classify specialization failures. Provides more useful stats, with lower overhead.#27701
Conversation
|
We should definitely turn on stats for debug builds, to be able to test it. But that's for another PR. |
Fidget-Spinner
left a comment
There was a problem hiding this comment.
I'll miss the old way a little -- it gave me an inkling of the exact attributes of types which were failing. However, this PR will definitely make collecting overall stats waaay better and the output seems less cluttered. Thanks Mark.
| #define SPEC_FAIL_LIST_NON_INT_SUBSCRIPT 8 | ||
| #define SPEC_FAIL_TUPLE_NON_INT_SUBSCRIPT 9 | ||
| #define SPEC_FAIL_NOT_TUPLE_LIST_OR_DICT 10 |
There was a problem hiding this comment.
These numbers are repeated from above. Or is that intentional?
There was a problem hiding this comment.
Yes, they can overlap with each other. They shouldn't overlap with the common values, though.
When experimenting, it should be easy enough to change the set of |
This PR classifies specializes failures, so that we can get numbers on specialization failures.
This replaces the previous dictionary of unstructured data with an array of numbers, which can be collated using the
summarize_specialization_stats.pyscript.The downside is that interpretation of the data now needs cross referencing with the list of
SPEC_FAIL#defines.IMO, being able to gather precise numerical values is easily worth that minor inconvenience.