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

5300 Gas Cost for Unnecessary Delete in ERC721Token.sol #977

Closed
mudgen opened this issue Jun 4, 2018 · 4 comments
Closed

5300 Gas Cost for Unnecessary Delete in ERC721Token.sol #977

mudgen opened this issue Jun 4, 2018 · 4 comments

Comments

@mudgen
Copy link

mudgen commented Jun 4, 2018

In the removeTokenFrom function ownedTokens[_from][lastTokenIndex] is set to 0 twice instead of once. The main reason this is not good beside redundant is because it costs gas. From my tests this unneeded redundancy costs 5300 gas.

Here is the code I am talking about:

 ownedTokens[_from][lastTokenIndex] = 0;
    // Note that this will handle single-element arrays. In that case, both tokenIndex and lastTokenIndex are going to
    // be zero. Then we can make sure that we will remove _tokenId from the ownedTokens list since we are first swapping
    // the lastToken to the first position, and then dropping the element placed in the last position of the list

 ownedTokens[_from].length--;

The first line obviously sets ownedTokens[_from][lastTokenIndex] to 0. Reducing the length of the array also sets ownedTokens[_from][lastTokenIndex] to 0.

So it makes sense to get rid of this line: ownedTokens[_from][lastTokenIndex] = 0;.

@come-maiz
Copy link
Contributor

Thanks for the report @mudgen. Can you please make a pull request making sure that the removeFrom is fully tested to ensure that the behaviour is preserved?

@mudgen
Copy link
Author

mudgen commented Jun 10, 2018

@ElOpio I don't have sufficient incentive/motivation to make a pull request and test this further. I tested it for myself and that is enough for me. I mentioned it to OpenZepplin to help out.

@come-maiz
Copy link
Contributor

Alright, thanks @mudgen. We'll take a look when our backlog is smaller, or when somebody else jumps to it.

@YZhenY
Copy link
Contributor

YZhenY commented Jun 13, 2018

I would love to work on this @ElOpio. Starting on it

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

No branches or pull requests

3 participants