Optimize toString #3573

CodeSandwich · 2022-07-23T23:16:06Z

Fixes #????

This PR reduces gas usage of Strings.toString for decimal numbers. Here are some results:

Input                                                                          | Current | New  | Gas saved
-------------------------------------------------------------------------------|---------|------|-----------------
0                                                                              | 131     | 458  | -327  (-249,62%)
1                                                                              | 833     | 458  | 375   (45,02%)
12                                                                             | 1383    | 534  | 849   (61,39%)
123                                                                            | 1933    | 611  | 1322  (68,39%)
1234                                                                           | 2483    | 687  | 1796  (72,33%)
12345                                                                          | 3033    | 735  | 2298  (75,77%)
1234567                                                                        | 4133    | 888  | 3245  (78,51%)
1234567890                                                                     | 5783    | 1059 | 4724  (81,69%)
123456789012345                                                                | 8533    | 1413 | 7120  (83,44%)
12345678901234567890                                                           | 11283   | 1708 | 9575  (84,86%)
123456789012345678901234567890                                                 | 16783   | 2357 | 14426 (85,96%)
1234567890123456789012345678901234567890                                       | 22289   | 2983 | 19306 (86,62%)
12345678901234567890123456789012345678901234567890                             | 27789   | 3574 | 24215 (87,14%)
123456789012345678901234567890123456789012345678901234567890                   | 33289   | 4252 | 29037 (87,23%)
1234567890123456789012345678901234567890123456789012345678901234567890         | 38795   | 4820 | 33975 (87,58%)
115792089237316195423570985008687907853269984665640564039457584007913129639935 | 43195   | 5345 | 37850 (87,63%)

(Edit: results updated for the newest commits) Each measurement was done in a separate dapptools test to remove memory usage bias. Solc was in version 0.8.13 with optimizer set to 1 million runs.

A little more gas can be pinched, e.g. manual string allocation with Yul saves ~119 gas, but that both complicates the codebase and makes the optimizer behavior harder to predict.

Tests are cleaned up and extended.

PR Checklist

Tests
Documentation
Changelog entry

Amxx · 2022-07-25T08:53:43Z

Thanks @CodeSandwich for this PR

Note: We could use the same length-search pattern for the hex version.

CodeSandwich · 2022-07-25T08:57:15Z

Yes, if this PR goes through, we can add these optimizations there too. One thing at a time 😃

contracts/mocks/StringsMock.sol

Amxx · 2022-07-25T12:25:53Z

contracts/utils/Strings.sol

+            if (value < 10) {
+                return string(abi.encodePacked(uint8(value + 48)));
+            }


We should try to remove that special case

We can't remove it entirely, we still need to handle the special case of 0. A change from if(value < 10) to if(value == 0) return "0" decreases gas for the case of 0 from 170 to 131, but for other single-digit numbers increases from 170 to 525.

Why do you want to remove it, is it to clean up the logic or for a different reason? If it's only to clean up, IMO the gas savings justify the tiny additional complexity, especially since single-digit conversions seem to be a common use case, but that's just that: an opinion.

we can, see my commit

This is the commit: CodeSandwich@8597e3d

~~The problem is that it creates bad output, in all cases except 0 it creates a string with length 1 too big.~~ Plus now all single-digit numbers have cost increased 3-fold to >500, not only 1 to 9. ~~Your commit also introduces bad powers of 10.~~ I need to look closer into this 🤔

Ok, I see that it'll work just fine, the change in powers of 10 counter the initial length of 1, very clever! But the gas usage for single-digit numbers is still much higher. What are the advantages?

IMO its easier to understand/review, which is always positive.

I'm love to see the gas number.

Also, I'm wondering what are the usecase for this function to be executed as part of a transaction and not in an offchain call. I think our initial approach was to optimize for deployment cost, assuming it would (almost) never be paid for anyway.

Does removal of the special case reduce a lot of bytecode? Lower gas usage is always a good thing, because we don't know how this code will be used. Otherwise this entire PR is pointless, it complicates the logic in exchange for lower gas. IMO we can keep all your changes including length = 1, but still restore the single-digit shortcut.

contracts/utils/Strings.sol

CodeSandwich · 2022-07-25T13:49:15Z

contracts/utils/Strings.sol

+
+            // compute log256(value), and add it to length
+            uint256 valueCopy = value;
+            if (valueCopy >> 128 > 0) {


if (valueCopy >= 1 << 128) { will be equivalent, but should be cheaper, the shifting will be evaluated at compilation time.

I'm not sure the shift is done at compile time. Can you confirm ?

As of 0.8.13, yes, I've changed some constants to 1 << X and the gas usage hasn't changed at all.

but should be cheaper

Why? I'm seeing the compiler emit code sequences that cost exactly the same for the two expressions.

PUSH1 0x1 PUSH1 0x80 SHL DUP2 LT
vs
PUSH1 0x80 DUP2 SWAP1 SHR ISZERO

I'm not sure what opcodes exactly it generates, but it's marginally cheaper, 30 gas in total or 6 gas per if, probably because it doesn't do any bit-shifting at all. I'm surprised that you got any SHL at all, so the compiler must've not precalculated the constants, did you enable the optimizer?

The gas difference is ridiculously low anyway, I don't have a strong opinion about which version is better. The current one (valueCopy >= 1 << N) is a little more consistent with the decimal toString, but that's just a matter of preference. There's no "old version" to revert to, it's a new piece of code, the old implementation was completely different.

did you enable the optimizer?

Yes. For constants Solidity will often prioritize code size before runtime cost.

contracts/utils/Strings.sol

CodeSandwich · 2022-07-26T21:27:48Z

I've pushed an optimization of the memory writing loop. I don't exactly understand why, streamlining the loop and putting the iszero command as the last thing of the loop just clicks with the optimizer. The new gas usage results:

0: 458
1: 458
12: 534
123: 611
1234: 687
12345: 735
1234567: 888
1234567890: 1059
123456789012345: 1413
12345678901234567890: 1708
123456789012345678901234567890: 2357
1234567890123456789012345678901234567890: 2983
12345678901234567890123456789012345678901234567890: 3574
123456789012345678901234567890123456789012345678901234567890: 4252
1234567890123456789012345678901234567890123456789012345678901234567890: 4820
115792089237316195423570985008687907853269984665640564039457584007913129639935: 5345 (8 fold decrease from master 😆)

The usage of the symbols table has zero impact on gas, but IMO it's much clearer than the addition of a magic number.

contracts/utils/Strings.sol

frangio · 2022-08-23T02:23:46Z

Sorry I'm late to this PR.

My thoughts are:

For loops in Yul have very unfamiliar syntax, at the moment we don't have any in the entire codebase, and I would prefer if that remained the case. The main gains in this PR are due to an optimized log10 implementation, and probably some more from removing bounds checks on array accesses. Some assembly is necessary for the second part but I would strongly prefer if the for loop was outside of that.
I would really appreciate if the log10 implementation was added as Math.log10 so it could be used on its own. That also implies some more testing though, so I would be ok with doing that in a later PR.
As I commented above, >= 1 << 128 vs >> 127 > 0 seems to not make a difference at all so I'd like us to revert the unrelated changes in Math.sol.

Amxx · 2022-08-23T09:31:57Z

I would really appreciate if the log10 implementation was added as Math.log10 so it could be used on its own. That also implies some more testing though, so I would be ok with doing that in a later PR.

Making a PR that includes Math.log10 and Math.log2 would be great.

Math.log2 could be used in Math.sqrt(uint256) and Strings.toHexString(uint256)
Math.log10 would be used in Strings.toString(uint256)

@CodeSandwich, would you be able to do that ?

contracts/utils/Strings.sol

frangio · 2022-08-24T01:44:49Z

contracts/utils/Strings.sol

        for (uint256 i = 2 * length + 1; i > 1; --i) {
-            buffer[i] = _HEX_SYMBOLS[value & 0xf];
+            buffer[i] = _SYMBOLS[value & 0xf];
            value >>= 4;
        }


This could be written in the same or similar way that the decimal toString.

frangio

LGTM

Co-authored-by: Hadrien Croubois <[email protected]> Co-authored-by: Francisco Giordano <[email protected]>

CodeSandwich added 2 commits July 24, 2022 01:12

Optimize toString

e0c9042

Set PR number

2292bf4

Amxx reviewed Jul 25, 2022

View reviewed changes

contracts/mocks/StringsMock.sol Outdated Show resolved Hide resolved

Amxx reviewed Jul 25, 2022

View reviewed changes

contracts/utils/Strings.sol Outdated Show resolved Hide resolved

CodeSandwich and others added 7 commits July 25, 2022 14:57

Express long numbers as powers

10a7a90

lint

029c82e

refactor toString()

365e07b

Merge branch into fast_toString

8597e3d

use the library name/selector in mocks & test

57af5c4

improve length estimation

e8e61fc

minimize PR change

7e81cc4

Amxx modified the milestones: 5.0, 4.8 Jul 25, 2022

CodeSandwich commented Jul 25, 2022

View reviewed changes

Amxx added 2 commits July 25, 2022 16:01

minimize PR change

eb7f013

gas optimization in toString() and sqrt()

2eeeb5c

CodeSandwich commented Jul 25, 2022

View reviewed changes

contracts/utils/Strings.sol Outdated Show resolved Hide resolved

Amxx and others added 2 commits July 25, 2022 16:47

fix > → >=

8f84142

Optimize writing loop

4eace99

Amxx reviewed Jul 27, 2022

View reviewed changes

contracts/utils/Strings.sol Show resolved Hide resolved

Amxx reviewed Jul 27, 2022

View reviewed changes

contracts/utils/Strings.sol Outdated Show resolved Hide resolved

Amxx reviewed Jul 27, 2022

View reviewed changes

contracts/utils/Strings.sol Show resolved Hide resolved

frangio reviewed Aug 24, 2022

View reviewed changes

contracts/utils/Strings.sol Outdated Show resolved Hide resolved

frangio reviewed Aug 24, 2022

View reviewed changes

CodeSandwich and others added 4 commits August 25, 2022 17:09

Less assembly

b9a4ae1

Merge branch 'master' into fast_toString

34ba82a

prettier

8e955af

revert unrelated changes

d3d66ac

frangio previously approved these changes Aug 31, 2022

View reviewed changes

Merge branch 'master' into fast_toString

b026166

frangio dismissed their stale review via b026166 August 31, 2022 22:59

frangio approved these changes Aug 31, 2022

View reviewed changes

frangio enabled auto-merge (squash) August 31, 2022 22:59

frangio merged commit 160bf1a into OpenZeppelin:master Aug 31, 2022

Amxx mentioned this pull request Sep 1, 2022

Add log2, log10 and log256 functions #3670

Merged

3 tasks

ronhuafeng added a commit to ronhuafeng/openzeppelin-contracts that referenced this pull request Sep 9, 2022

Optimize toString (OpenZeppelin#3573)

0790afa

Co-authored-by: Hadrien Croubois <[email protected]> Co-authored-by: Francisco Giordano <[email protected]>

frangio mentioned this pull request Sep 16, 2022

Optimize Strings.toString(uint) implementation #3190

Closed

JulissaDantes pushed a commit to JulissaDantes/openzeppelin-contracts that referenced this pull request Nov 3, 2022

Optimize toString (OpenZeppelin#3573)

20e2a3a

Co-authored-by: Hadrien Croubois <[email protected]> Co-authored-by: Francisco Giordano <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Optimize toString #3573

Optimize toString #3573

CodeSandwich commented Jul 23, 2022 •

edited

Loading

Amxx commented Jul 25, 2022

CodeSandwich commented Jul 25, 2022

Amxx Jul 25, 2022

CodeSandwich Jul 25, 2022 •

edited

Loading

Amxx Jul 25, 2022

CodeSandwich Jul 25, 2022 •

edited

Loading

CodeSandwich Jul 25, 2022

Amxx Jul 25, 2022

CodeSandwich Jul 25, 2022

CodeSandwich Jul 25, 2022 •

edited

Loading

Amxx Jul 25, 2022

CodeSandwich Jul 25, 2022

frangio Aug 23, 2022

CodeSandwich Aug 25, 2022 •

edited

Loading

frangio Aug 30, 2022

CodeSandwich commented Jul 26, 2022

frangio commented Aug 23, 2022

Amxx commented Aug 23, 2022

frangio Aug 24, 2022

frangio left a comment

Optimize toString #3573

Optimize toString #3573

Conversation

CodeSandwich commented Jul 23, 2022 • edited Loading

PR Checklist

Amxx commented Jul 25, 2022

CodeSandwich commented Jul 25, 2022

Choose a reason for hiding this comment

CodeSandwich Jul 25, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CodeSandwich Jul 25, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CodeSandwich Jul 25, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CodeSandwich Aug 25, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CodeSandwich commented Jul 26, 2022

frangio commented Aug 23, 2022

Amxx commented Aug 23, 2022

Choose a reason for hiding this comment

frangio left a comment

Choose a reason for hiding this comment

CodeSandwich commented Jul 23, 2022 •

edited

Loading

CodeSandwich Jul 25, 2022 •

edited

Loading

CodeSandwich Jul 25, 2022 •

edited

Loading

CodeSandwich Jul 25, 2022 •

edited

Loading

CodeSandwich Aug 25, 2022 •

edited

Loading