-
Notifications
You must be signed in to change notification settings - Fork 23
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
Ensure Firefox frame table subcategory fields are always included #129
Conversation
I actually found a few more things that should be fixed: When the category is non-null, the subcategory should also be non-null. So it's better to make it an all-zero column rather than an all-null column. |
Oh, one more thing: For cases where the same frame is used by different stack nodes with different categories, those frames need to be split up so that the right stack node category can be computed from the frame category. See firefox-devtools/profiler#5369 (comment) |
3eb0327
to
ed4d30b
Compare
Noted. I've actually gone ahead and just put the correct subcategory indexes in there for now. I’ll wait for @jhawthorn to see if there’s a reason for not wanting to do that.
I think we already comply with this here: vernier/lib/vernier/output/firefox.rb Line 49 in c4e1980
|
Ah, perfect. The profiles which are linked in the readme were probably generated before that change then. |
Oh interesting, maybe this explains why we don't set the subcategory on the frames. I'll look into reworking this. |
ed4d30b
to
a3b5fd2
Compare
Okay it seems the frames were intentionally reused in this change, and I don't think that's related to the subcategory omission in any way (that may have just been an oversight/seen as a redundancy). I think I'll merge this as is and tackle the frame separation problem as a separate issue and PR. |
Closes #128
I wonder why we set the frame category but not the subcategory here 🤔
Anyway, I've kept it asSee #129 (comment).nil
to maintain behaviour while ensuring we conform to the expected Firefox type.