You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On JVM, instead of reading each character separately and then encoding it to UTF-8 and writing to a buffer, it might be faster to:
extract chars to a CharArray and then iterate over it;
simply use toByteArray.
For other libraries, namely kotlinx.serialization, some of these approaches performed better. While quick ad-hoc experiments didn't show any pros for kotlinx-io, it does make sense to investigate it thoroughly.
The text was updated successfully, but these errors were encountered:
Combination of String::toByteArray and UnsafeBufferOperations::moveToTail show better performance when it comes to strings whose chars could be encoded using same-length byte sequences. However, the current implementation significantly outperforms String::toByteArray-based approach on strings where characters require byte sequences of variadic lengths.
And, of course, String::toByteArray result in higher allocation rate.
In serialization, we leverage intrinsified String::getChars (pros: vectorized, much faster compact strings unpacking, no rangechecks) and also rely on the fact that our CharArrays are pooled, leading to no allocations.
On JVM, instead of reading each character separately and then encoding it to UTF-8 and writing to a buffer, it might be faster to:
For other libraries, namely
kotlinx.serialization
, some of these approaches performed better. While quick ad-hoc experiments didn't show any pros forkotlinx-io
, it does make sense to investigate it thoroughly.The text was updated successfully, but these errors were encountered: