Skip to content
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

core/vm/memory: fix Memory.Set32 use make fill with 0 to []byte is better #24776

Closed
wants to merge 1 commit into from
Closed

Conversation

xavierzho
Copy link

I think using make function fill []byte is obvious than literal,
Memory.GetCopy add "GetCopy" prefix to comment.

…tter than literal and Memory.GetCopy add "GetCopy" prefix to comment
Copy link
Contributor

@holiman holiman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is an improvement, other than the fix for the docstring on GetCopy

panic("invalid memory: store empty")
}
// Zero the memory area
copy(m.store[offset:offset+32], []byte{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0})
copy(m.store[offset:offset+bit32], empty)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see any reason why this would be faster. As it was, the compiler can replace the []byte{...} with a constant, which it might not do with a dynamically allocated empty.
I have a recollection that we added this ugly hack a long time ago, when we detected that it was indeed faster to initalize it like this.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this performance gap is acceptable.

@@ -22,6 +22,8 @@ import (
"github.com/holiman/uint256"
)

const bit32 = 32
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why a constant bit32 is easier to read than 32 ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, This is my code cleanliness.

@holiman
Copy link
Contributor

holiman commented Apr 27, 2022

Oh, see #16939 (comment) for more context

@holiman
Copy link
Contributor

holiman commented Apr 29, 2022

I think this performance gap is acceptable.

The performance of the evm is very important, and we're usually very conservative in making changes. Making changes only to somewhat increase legibility but incur performance penalty is not worth it for us.

Still. thanks for the effort!

@holiman holiman closed this Apr 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants