-
Notifications
You must be signed in to change notification settings - Fork 745
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
Use SmallVector in TypeUpdating::updateParamTypes() #5579
base: main
Are you sure you want to change the base?
Conversation
src/wasm-builder.h
Outdated
@@ -229,6 +230,13 @@ class Builder { | |||
ret->finalize(type); | |||
return ret; | |||
} | |||
template<size_t N> | |||
Block* makeBlock(const SmallVector<Expression*, N>& items) { |
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.
Would it be worth deduplicating all the different versions of makeBlock
into a few templatized versions that can take any iterable for the items?
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 tried again yesterday actually, but I just run into C++ stuff I can't figure out, sadly.
The problem is that we have a version makeBlock(Expression* first)
and others that take a list as their single parameter, and it gets confused - it tries to use the list versions for subtypes of Expression
, and then errors on not having .size()
in them. To fix that, I've tried all manner of std::is_base_of
inside of the C++ magic to ignore a template. I also tried more basic SFINAE stuff like ordering them so the erroring one is first. But nothing seems to work for me, and after an hour or so I gave up. Maybe that just isn't possible for some reason?
If you can figure it out though that would be incredible!
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.
How much does this improve performance, out of curiosity? |
I tried the artifacts on this branch to run the same test in the same environment in #5561. The run time is now down to 18s. |
@tlively I didn't see a speed difference in my own local tests (perhaps because I can't reproduce the malloc contention issue on my machine). But I verified that on common codebases there are fewer params than this, and it will definitely save some work in those cases, so it looks right in general. @TerrorJack Interesting, to what is that compared to? I see various numbers in that issue but all are much larger than 18s so I'm not sure which is relevant. |
I'm still confused @TerrorJack , sorry, since the toplevel post contains this:
To which of those numbers should the 18 seconds be compared? The 219 seems too high (this PR can't help that much) but the 14 is too low (since you say it decreased, not increased). Apologies, I'm probably not reading something right... |
Noticed when profiling for #5561 (comment)
Helps #4165