In order the improve the performance of the package I've modified the while loop. Instead of going through the while loop till num has reached 0 the while loop now loops till num has reached 1. The
advantage is that it eliminates the need to check for !num inside the while loop.
To compensate for the lost while iteration it is necessary to manually perform the concat of str to res which otherwise would've taken place.
If the method is called for the same string as the last call, the method will now check if the cached result is long enough to fulfil the request before getting to the while loop. If the cached string is long enough the method will immediately return the result. This is needed because else the method will execute the manual concat just before returning the result which would unnecessarily increase the length of the cached string.
In addition the value of res is set to the exact length that was requested. This is an optimisation for cases where a consecutive call for the same string is performed with a higher number of iterations than the previous one(s). This could lead to res with a substantial longer string than needed. It is a minor tweak to reduce the memory footprint in certain cases.
Benchmarks
I've updated the benchmarks so it is possible to compare the changes against v1.5.4. To this end I've added a new file in the code folder with the content of index.js for version 1.5.4.
In addition I've had to update the benchmarked dev dependency to version 0.2.5. The specified version only wrote the names to the consoles but didn't perform any actual tests. The update of the benchmarked package is not included in the pull request as I wasn't sure if it was something specific to my machine.
These are the results of the benchmarks from my machine:
# fixtures/5.js (43 bytes)
repeat-string x 21,380,433 ops/sec ±1.19% (86 runs sampled)
repeat-string-1.5.4 x 21,075,370 ops/sec ±1.03% (88 runs sampled)
repeating x 13,254,540 ops/sec ±1.65% (86 runs sampled)
native x 14,420,551 ops/sec ±1.04% (89 runs sampled)
fastest is repeat-string
# fixtures/50.js (46 bytes)
repeat-string x 26,039,969 ops/sec ±1.33% (87 runs sampled)
repeat-string-1.5.4 x 22,890,035 ops/sec ±1.02% (85 runs sampled)
repeating x 10,089,725 ops/sec ±0.96% (91 runs sampled)
native x 10,660,976 ops/sec ±1.14% (88 runs sampled)
fastest is repeat-string
# fixtures/250.js (47 bytes)
repeat-string x 26,100,331 ops/sec ±1.13% (85 runs sampled)
repeat-string-1.5.4 x 20,422,690 ops/sec ±1.19% (84 runs sampled)
repeating x 7,493,552 ops/sec ±1.07% (88 runs sampled)
native x 6,547,061 ops/sec ±1.11% (89 runs sampled)
fastest is repeat-string
# fixtures/2000.js (48 bytes)
repeat-string x 25,492,010 ops/sec ±1.00% (87 runs sampled)
repeat-string-1.5.4 x 23,295,895 ops/sec ±1.08% (89 runs sampled)
repeating x 6,842,025 ops/sec ±0.93% (88 runs sampled)
native x 6,966,759 ops/sec ±1.45% (87 runs sampled)
fastest is repeat-string
# fixtures/20000.js (49 bytes)
repeat-string x 23,297,103 ops/sec ±1.15% (90 runs sampled)
repeat-string-1.5.4 x 21,419,016 ops/sec ±1.14% (87 runs sampled)
repeating x 6,081,880 ops/sec ±1.09% (87 runs sampled)
native x 5,709,154 ops/sec ±1.00% (85 runs sampled)
fastest is repeat-string
In order the improve the performance of the package I've modified the while loop. Instead of going through the while loop till
num
has reached0
the while loop now loops tillnum
has reached1
. The advantage is that it eliminates the need to check for!num
inside the while loop.To compensate for the lost while iteration it is necessary to manually perform the concat of
str
tores
which otherwise would've taken place.If the method is called for the same string as the last call, the method will now check if the cached result is long enough to fulfil the request before getting to the while loop. If the cached string is long enough the method will immediately return the result. This is needed because else the method will execute the manual concat just before returning the result which would unnecessarily increase the length of the cached string.
In addition the value of
res
is set to the exact length that was requested. This is an optimisation for cases where a consecutive call for the same string is performed with a higher number of iterations than the previous one(s). This could lead tores
with a substantial longer string than needed. It is a minor tweak to reduce the memory footprint in certain cases.Benchmarks I've updated the benchmarks so it is possible to compare the changes against v1.5.4. To this end I've added a new file in the code folder with the content of index.js for version 1.5.4.
In addition I've had to update the
benchmarked
dev dependency to version 0.2.5. The specified version only wrote the names to the consoles but didn't perform any actual tests. The update of thebenchmarked
package is not included in the pull request as I wasn't sure if it was something specific to my machine.These are the results of the benchmarks from my machine: