You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 27, 2023. It is now read-only.
The Go compile is smart enough to perform loop invariant code motion. I don't know if it does in this case, but it's not a guarantee that performing the optimization by hand would actually be doing anything that isn't already being done by the compiler. The generated assembly would have to be analyzed to determine if the compiler is performing the optimization or not.
@davebryson@adlerjohn does it make sense to analyze the generated assembly in this case? Also, is there anything else that needs further clarification? Otherwise, I'd close this issue.
Yeah, looking at the line in question: independent from how the go compiler handles this, I think it makes sense to move this for readability (to save others the cognitive overhead and time thinking about this).
Just noticed this while working through the code. Does this need to be calculated on every iteration?
https://github.com/lazyledger/smt/blob/master/smt.go#L289
When I move it above the for loop, all test still pass.
The text was updated successfully, but these errors were encountered: