micro-memory optimization: change const int copy_depth to unsigned char #3745

pull ianks wants to merge 1 commits into bitcoin:master from ianks:master changing 1 files +1 −1

ianks commented at 7:46 PM on February 25, 2014: none

b/c it fits in 8bit value
micro-memory optimization: change const int copy_depth to unsigned char b/c it fits in 8bit value 28b94ffd2e
laanwj commented at 8:23 PM on February 25, 2014: member

Please show benchmarks if you submit optimizations...

But I'm fairly sure that there is no point in this, the value will end up in a 32 or 64 bit register regardless.
BitcoinPullTester commented at 8:27 PM on February 25, 2014: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/28b94ffd2e16fce95af256e7abf9b902690ea15b for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
luke-jr commented at 8:31 PM on February 25, 2014: member

If it wasn't const (which the compiler can do everything with at compile-time), it'd actually be slower since it has to handle overflows and such. "int" is supposed to be the fastest integer type, at least 16-bit wide...
laanwj commented at 8:40 PM on February 25, 2014: member

Yes, in general there is no gain in using smaller integer types, unless it is to save memory in a packed structure or array.
laanwj closed this on Feb 25, 2014
gmaxwell commented at 11:55 PM on February 25, 2014: contributor

FWIW, this change wouldn't have changed the object code at all.
DrahtBot locked this on Sep 8, 2021

Contributors