Closed AdrianRaFo closed 4 years ago
Hood benchmark comparison:
:heavy_check_mark: Decoding
(Threshold: 143.8414158130772)
Benchmark | Value |
---|---|
master_benchmark | 11179.526606635085 |
helios_benchmark | 11377.697188323946 |
:warning: Decodingfromraw
(Threshold: 250.0)
Benchmark | Value |
---|---|
master_benchmark | 7487.846451793273 |
helios_benchmark | 7437.901652840776 |
:heavy_check_mark: Parsing
(Threshold: 250.0)
Benchmark | Value |
---|---|
master_benchmark | 22600.88142860002 |
helios_benchmark | 22702.883111702744 |
You're replacing one object allocation with one object allocation + some extra code. There are no such wins when using by lazy
. In memory it's an object with an invoke property that's called every time the value is accessed.
But the lazy should create just one object the first time is used, isn't it? using fun we were creating one object each time
No, lazy creates two objects. A structure to do lazy initialization and the actual encoder when requested for the first time. This mechanism is heavier than just val
since it uses locks and synchronization so potentially even slower than just val
. reference
Ok then, I'll change them to regular vals
Create lazy instances for all the possible encoders and decoders in order to improve the performance