Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize the usuage of memory and cpu about BoundSql #2906

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

743834110
Copy link

Instantiating a HashMap of BoundSql with a specified map size, to avoid frequent the memory of allocation and deallocation.
For example the foreach usage:

<select id="selectPostIn" resultType="domain.blog.Post"> SELECT * FROM POST P WHERE ID in <foreach item="item" index="index" collection="list" open="(" separator="," close=")"> #{item} </foreach> </select>

The HashMap default initial size is 16, It will be cost more memory and cpu in expanding the capacity, using a designated size will reduce this process.

@harawata
Copy link
Member

Hello @743834110 ,

Thank you, but we are not doing this unless you provide data that proves the effect of the change.

@hazendaz
Copy link
Member

Hello @743834110 ,

Thank you, but we are not doing this unless you provide data that proves the effect of the change.

Normally it would make sense but am I reading this correctly, the used value is not the same as the parameters. Its additional parameters so setting it to parameters doesn't make sense as that is loaded separately?

@743834110
Copy link
Author

Thanks @hazendaz @harawata,
I did a <foreach> profiling with JMH.

BoundSqlOptimizationTest.testHintMapSizeMap       500  avgt    5   5670097.176 ±   346105.727  ns/op
BoundSqlOptimizationTest.testHintMapSizeMap      1000  avgt    5   12844140.381 ±   525269.634  ns/op
BoundSqlOptimizationTest.testHintMapSizeMap      2000  avgt    5   30320524.941 ±  1037706.113  ns/op
BoundSqlOptimizationTest.testHintMapSizeMap      5000  avgt    5   69476886.893 ± 10238697.167  ns/op
BoundSqlOptimizationTest.testPlainMap             500  avgt    5   5674822.605 ±   217978.565  ns/op
BoundSqlOptimizationTest.testPlainMap            1000  avgt    5   12921529.643 ±   414002.851  ns/op
BoundSqlOptimizationTest.testPlainMap            2000  avgt    5   30468800.957 ±   607199.482  ns/op
BoundSqlOptimizationTest.testPlainMap            5000  avgt    5   72581254.172 ±  3087016.712  ns/op

It seens that a little change and as you said the used value is not the same as the parameters, In the most usage cases without foreach, the size of additional parameters will be 0, so doing this may have no effects.
But in foreach cases, the size of additional parameters very close to parameters because of the placeholder handling in DynamicSqlSource.

@harawata
Copy link
Member

additionalParameters contain global variables etc., so you really cannot know the actual size.

But in foreach cases, the size of additional parameters very close to parameters because of the placeholder handling in DynamicSqlSource.

Once we merge #2760 (in 3.6.x or 4.x), this presumption won't be true anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants