While creating benchmarks and profiling for the constructor injection ticket, I stumbled upon two cases which could be optimised, and both reduce memory allocation and runtime for very large result sets.
I did not want to include this in the previous PR as it is already huge, and these two improvements can be standalone.
Here are the benchmarking results using the same benchmark I created for the previously mentioned ticket.
coverage: 87.118% (+0.001%) from 87.117%
when pulling 7e032612b7e1055497535303a42b1ed75239cef9 on epochcoder:fix/minor-performance-improvement-resultsethandler
into 0ec8fcbf0c3d0ef11241f8880ee10adaa2f6fbba on mybatis:master.
While creating benchmarks and profiling for the constructor injection ticket, I stumbled upon two cases which could be optimised, and both reduce memory allocation and runtime for very large result sets.
I did not want to include this in the previous PR as it is already huge, and these two improvements can be standalone. Here are the benchmarking results using the same benchmark I created for the previously mentioned ticket.
For easy reference, here are the same benchmarks without this change:
As you can see, it does not really affect retrieving a single row, but improvements start to accumulate as our result set gets bigger