Tag Archive | refactoring

Benchmarking the famous refactoring of GeneratePrimes in Robert C. Martin’s ‘Clean Code’

Inspired by Tomasz Nurkiewicz’ blog post about how aggressive the inlining capability of the Java Virtual Machine is (original blog post), I asked myself what impact the refactorings to the famous GeneratePrimes class in Robert C. Martin’s book ‘Clean Code’ (see page 71) are. Therefore I set up a small benchmark project that can be found here on GitHub: https://github.com/siom79/generate-primes-cleancode-benchmark.

Under src/main/java you will find the two classes as they are published in the book and under src/test/java a unit test that runs the generatePrimes() method of the two classes with different values for the argument maxValue, ranging from 10 to The unit test prints out the measured time in milliseconds like this:

OneMethod : 1083,00 ms for 10
PlentyMethods: 490,17 ms for 10
OneMethod/PlentyMethods: 2,21 (< 1 means OneMethod is faster)
OneMethod : 12,40 ms for 100
PlentyMethods: 19,68 ms for 100
OneMethod/PlentyMethods: 0,63 (< 1 means OneMethod is faster)
OneMethod : 125,75 ms for 1000
PlentyMethods: 179,22 ms for 1000
OneMethod/PlentyMethods: 0,70 (< 1 means OneMethod is faster)
OneMethod : 1386,68 ms for 10000
PlentyMethods: 2069,76 ms for 10000
OneMethod/PlentyMethods: 0,67 (< 1 means OneMethod is faster)
OneMethod : 10096,85 ms for 100000
PlentyMethods: 10365,03 ms for 100000
OneMethod/PlentyMethods: 0,97 (< 1 means OneMethod is faster)
OneMethod : 26232,72 ms for 1000000
PlentyMethods: 8215,29 ms for 1000000
OneMethod/PlentyMethods: 3,19 (< 1 means OneMethod is faster)
OneMethod : 184577,74 ms for 10000000
PlentyMethods: 184149,59 ms for 10000000
OneMethod/PlentyMethods: 1,00 (< 1 means OneMethod is faster)
OneMethod : 2100707,11 ms for 100000000
PlentyMethods: 2103006,56 ms for 100000000
OneMethod/PlentyMethods: 1,00 (< 1 means OneMethod is faster)

The logging statement beginning with OneMethod is the old-styled implementation which computes all prime numbers up to the given maximum value with only one method, whereas the statement beginning with PlentyMethods uses the refactored version using plenty methods for the implementation of the same algorithm. As you will notice, the difference between both implementations converges against 1.00. This means that after some time all private methods of the refactored implementation have been inlined and do not cause any runtime overhead. Until 100.000 the one method implementation is faster, afterwards (interestingly except for the 1.000.000 measurement) the difference in runtime is 1. Surprisingly the first measurement shows up that the plenty method implementation is even faster than the old-styled implementation.

PS: The measurement were taken on the following setup: Intel Core i5, 2.4 GHz, 4GB RAM, 64Bit; Windows 7, Java(TM) SE Runtime Environment (build 1.7.0_21-b11).