change the way to caculate the size of string

[j-joker]

I think this way is better

[coveralls]

Coverage decreased (-0.5%) to 84.912% when pulling 0324aff on j-joker:master into 2384653 on lemire:master.

[lemire]

Please merge the following commit
a5886f7

and run mvn test before and after your change. It will measure in a rough but sufficiently accurate manner the running time of the string estimation.

We want to make sure that we do not degrade the performance since this function is called repeatedly, possibly millions of times. It also does something that is relatively unimportant (produce a memory usage estimation) so we do not ever want it to have an impact on performance.

Here is what it might look like...

$ mvn test
(...)
Running com.google.code.externalsorting.ExternalSortTest
#ignore = 67412000
[performance] String size estimator uses 1.116796875 ns per string
#ignore = 67412000
[performance] String size estimator uses 1.120703125 ns per string
#ignore = 67412000
[performance] String size estimator uses 1.1216796875 ns per string
#ignore = 67412000
[performance] String size estimator uses 1.116796875 ns per string
#ignore = 67412000
[performance] String size estimator uses 1.1138671875 ns per string
#ignore = 67412000
[performance] String size estimator uses 1.116796875 ns per string
#ignore = 67412000
[performance] String size estimator uses 1.1197265625 ns per string
#ignore = 67412000
[performance] String size estimator uses 1.116796875 ns per string
#ignore = 67412000
[performance] String size estimator uses 1.112890625 ns per string
#ignore = 67412000
[performance] String size estimator uses 1.116796875 ns per string

[lemire]

I think that the figure "8" here assumes are 64-bit JVM.

[lemire]

I am very concerned about the performance of this function. We designed the estimator to be dirt cheap ((s.length() * 2) + OBJ_OVERHEAD). You are proposing something that looks much more expensive. See my comments on the PR about benchmarking this function.

As the name implies, I think we want an estimation, and we want to get it in not much more than 1 ns on a desktop PC.

[lemire]

I an going to close this since the submitter never got back to us.