Fix performance bug with large number of unnamed parameters

[tttomat19]

Preamble:
Consider the following sql script: select some from table where id in (:args)
Where args is a 10k items list
It does not look good, but people do it anyways, or maybe just when the system scales up, and it slowly grows from 100 items to 10k items

The problem
In such conditions QueryMapper.getUniqueName needs to figure out the names for each of the elements in the in (:a1,:a2,:a3, :a10000) list, it does so by generating a name by counter and tries to lookup the name in the parameters hashmap
But if the argument list is so large it traverses the map over and over again
Ultimately it results in O(N^2) complexity (where operation behind is a hashmap lookup)
The symptom is a very high CPU consumption, and it is really slow

The fix
The suggested fix is just to skip most of the counter-hashmap traversal, just make the counter go forward
We still need the loop to guarantee generated names are unique

More on the problem
While 10k case is just very obvious to see and detect but also
My guess that likely a lot of code out there, having 50+ of arguments invisibly suffer and the fix should probably help them too

I'm sorry about no tests, the problem here that the nature of the bug is whether it works slow, I'm not sure if there are any load tests or something for this repo

[schauder]

I don't think your proposed change fixes the problem.

The problem is if you have a large array of arguments, for the n-th argument, you are still looping over n-1 potential names, before finding a unique one.

In order to avoid that you'd need to preserve the state of name generation, between invocation.

If you can provide an actual fix, please amend the PR.

[tttomat19]

Hi, thank you for reply!

The state of name generation is already somewhat preserved in params hashmap in the outher method calls
After each time getUniqueName is called, the values (unmodifiable view of the params hashmap) size gets increased (it gets new wrapped view each time it enters getUniqueName)

I can see some possible case when the suggested approach will not work, but it requires actively trying to attack this code by somehow injecting sql param names with numbers before.
In most other cases this should make better, I believe
Would it be sufficient if I could demonstrate it works in common case? (I mean not the text below, but maybe like some actual tracing)

Consider the example: select * from t where id in (:args) where args is 5 in size
Current version tries names (0-indexed correspondence with args array)
0 - test for presence - args - ok
1 - test for presence - args1 - ok
2 - test for presence - args1 - nok - args2 - ok
3 - test for presence - args1 - nok - args2 - nok - args3 - ok
4 - test for presence - args1 - nok - args2 - nok - args3 - nok - args4 - ok
so it's kinda triangular/half-square shape, thus N^2

New version works the other way:
0 - test for presence - get size = 0 - args0 - ok
1 - test for presence - get size=1 - args1 - ok
2 - test for presence - get size=2 - args2 - ok
3 - test for presence - get size=3 - args3 - ok
4 - test for presence - get size=4 - args4 - ok

also it seems version should work for multiple arg arrays ok