-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Tasks flamegraph generation #3048
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
This issue is also being tracked on Linear. We use Linear to manage our development process, but we keep the conversations on Github. LINEAR-ID: 06ae891e-a08f-4d58-b99a-8e90931bcd84 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will review this again later because I want to understand a bit better the runtime part, but this should work as an initial review.
} | ||
|
||
const children = toFold.children.map((c) => foldFramegraph(c)); | ||
children.sort((a, b) => (a.parallel === b.parallel ? 0 : 1)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks suspicious to me. It seems like the intention is to put all the parallel items together, but I'm pretty sure that's not what this code will do.
My other problem is that whatever order is set here will be broken by the next sort.
What would make sense to me would be to put all the parallel items at the beginning, and the non-parallel at the end, and to then sort each half by name:
children.sort((a, b) => {
if (a.parallel === b.parallel) {
return a.name.localeCompare(b.name);
}
return a.parallel ? -1 : 1;
});
But I don't know if this is what you had in mind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intended behavior is similar to what you proposed. But take into account that Array.prototype.sort
is a stable sort.
We first sort by parallel, then by name. So that all of the children with the same name are together, and within a name-group, the parallel ones are also together.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please ping me on slack if you want to go over this together.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand this now. What I didn't understand was that the goal is to have the items grouped by name, and sorted internally by parallel, not the other way around (sorted by parallel state, and internally by name).
We need to fix the sort by parallel to return a -1
too though.
Co-authored-by: Franco Victorio <victorio.franco@gmail.com>
I just answered and/or resolved all the comments |
First PR of the compilation times optimization effort.
This PR introduces a Hardhat argument
--flamegraph
, which creates a flamegraph of the Hardhat tasks.