Performance Improvement for `randomInt` about es-toolkit

[kms0219kms]

@sossost , 사실 랜덤은 보통 양수에서 많이 발생하고 음수에서는 잘 일어나지 않습니다. Math.random()도 음수를 지원하진 않아서, 야매로 작업해야 합니다.

이 라이브러리는 속도와 안정성 두가지 모두 중요시 하는 라이브러리이기 때문에, 이 방식으로의 전환은 조금 조심해야 한다는 부분에서는 동의합니다만, 본 이슈를 통해 본 라이브러리가 중요시 하는 부분 등을 전체적으로 확인할 수 있는 계기가 되면 좋겠습니다.

In fact, randomness usually occurs a lot in positive numbers and rarely occurs in negative numbers. Math.random() also does not support negative numbers, so you have to work with it manually.

Since this library is one that values ​​both speed and stability, I agree that you need to be a little cautious when switching to this method, but I hope that this issue will serve as an opportunity to check the important aspects of this library as a whole.

[sossost]

@kms0219kms However, the random function supports negative ranges and will generate random numbers in the range above minimum (inclusive) and below maximum (exclusive).
So for consistency in implementation, math.floor seems to be better suited for the simplicity case.
It seems like a good case to think about the performance benefits �and simplicity of implementation.

[raon0211]

In my opinion, we should consider using bitwise operators only if there's a significant performance improvement.

However, based on the information provided by @kms0219kms (link), the performance difference doesn't seem substantial enough to justify the loss of readability.

For now, I suggest we prioritize simplicity in our implementation.

[kms0219kms]

벤치마크는 https://jsperf.app/pugihi 에서 확인 가능합니다.

[sossost]

Sorry I deleted and rewrote the comment.

Personally, I think Math.floor is better suited to the principles of implementation simplicity that this library stands for in terms of consistency and readability, unless the performance benefits are significant enough.
Also, the double tilde operator behaves differently for positive and negative numbers.
What do you think?

[kms0219kms]

In my opinion, we should consider using bitwise operators only if there's a significant performance improvement.

However, based on the information provided by @kms0219kms (link), the performance difference doesn't seem substantial enough to justify the loss of readability.

For now, I suggest we prioritize simplicity in our implementation.

네, 현재 비트연산으로의 floor처리는 일반적인 PC환경에서는 성능차이가 존재하나 유의미한 정도로 크진 않습니다.

모바일에서는 3~5% 정도 속도가 빠른 유의미한 결과가 나오긴합니다만, 가독성과 안정성 손실을 정당화할 만큼 유의미하진 않다는 의견에는 동의합니다.

앞으로 나아갈 방향이 이미 명확하게 결정된 것으로 보이므로 이슈를 마무리하겠습니다.

Yes, there is a performance difference in the floor using current bit operations in a general PC, but it is insignificant.

On mobile, there are meaningful results about 3-5% faster, but I agree that it is not significant enough to justify the loss of readability and stability.

I would close this issue as the pathway forward has already been clearly decided.