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
cmd/compile: NilCheckDeep performance regression #25389
Comments
Running compilerbench with reduced size, shows compile time degradation, so NilCheckDeep looks like a bad benchmark. Should we just remove it altogether? |
This doesn't surprise me. For those stack-allocate changes I always tried to choose the smallest cap constant that would cover most of the calls. Reducing the cap will negate the effect and actually make things worse, because if we stack-allocate small (like with cap = 8) and then most calls actually go over 8, we'll have to do even more work because we'll often need to move the worklist to the heap.
Even if it doesn't reflect real-world compiler performance, it could still be useful as a microbenchmark for that specific part of the compiler. The comment says:
which makes sense. My vote is to keep it, and also keep my stack-allocate change (since it makes the compiler faster); and ignore the |
@ALTree I don't have time to test right now, but wouldn't something like this help a bit? or would it still trigger the zeroing?
|
@OneOfOne Just checked, they generate basically the exact same code. Both go on the stack and then there's a |
Agreed, closing. |
After 00c8e14 NilCheckDeep benchmark shows significant regression:
This is caused by extra time spent in zeroing 256 bytes for:
Reducing 64 to 8 removes degradation
The text was updated successfully, but these errors were encountered: