Poor performance compared to moshi (up to 37x) on Android device #1156
Comments
|
Same problem |
|
++ |
|
This might be an issue with Android, as I conducted a benchmark with Jackson, Kotlin Serialization, and Moshi, and the Kotlin-based serialization consistently came in faster than Moshi (although slower than Jackson). GC JMH profile: Stack JMH profile: You can download the source code for this benchmark here. Environment
|
|
Just from glancing at those stackframes in Moshi, you appear to be using a It's also worth noting that in the common cases such as deserializing from the file system or the network, Moshi can stream the bytes into the decoder whereas this library requires them to have been fully buffered (and UTF-8 decoded, for JSON). |
|
@JakeWharton I'm not sure who you're responding to, as both my benchmark and the benchmark from @KarenkovID are deserializing JSON from a string value, both with Moshi and with the Kotlin Serialization library. |
|
That's leaving a lot of performance on the table for Moshi and is generally not how it's used in practice. |
|
But what @KarenkovID is reporting is that even when using Moshi in an inefficient manner vis-a-vis passing in a string, it's *still* markedly faster than using Kotlin's serialization library. |
|
@severn-everett , you benchmark example doesn't use my models and responses. You can compare models and json strings from my and your archive. My responses are huge and Kotlin data classes has a lot of fields and classes. You can try to run you benchmark with my models and responses. |
|
@KarenkovID I did that and was compiling the result just now. Here's one of the stack analyses for Kotlin's serializer: |
|
@severn-everett and you test machine uses i7-8550U with 16gb ram, which match more powerful than average android devise, which uses ARM cpu |
|
I wanted to check for whether this was an Android/limited device issue or a
library issue, and given that the updated JMH tests produce the same
results as your tests, it looks like it's the latter.
Op do 22 okt. 2020 19:24 schreef Karenkov Igor <notifications@github.com>:
… @severn-everett <https://github.com/severn-everett> and you test machine
uses i7-8550U with 16gb ram, which match more powerful than average android
devise, which uses ARM cpu
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1156 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC7SZ4LPACM4Q6J36UFCVALSMBTD5ANCNFSM4SZQJCEA>
.
|
qwwdfsad
added a commit
that referenced
this issue
Oct 22, 2020
…or in order to avoid allocation of nullable serializer and descriptor. Also, slightly reduce bytecode size Fixes #1156
|
Thanks for the self-contained report! After my fix, the original benchmark shows significant improvement: |
|
@qwwdfsad thank you for quick solving the problem! It is really nice that I can stop migration to moshi now 😄 Can you tell when it will be released? It is really important performance fix for our project and it'll be nice to have opportunity just upgrade lib version. Otherwise, I will have to fork project. |
|
No need to fork. It is already in a branch (and pull request) #1159 |
|
I know, but it's not released) |
|
1.0.x is going to be released around next week |
|
@KarenkovID @OsinniyApps @Merlinkoss it's great that you've published your benchmarks based on the real world Okko data. |
|
@qwwdfsad you can publish our code. Response structure is public and can be taken from Non-auth response to https://okko.tv |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
KxSerialization works mach slower than Moshi.
Benchmarks
I've measured performance using android instrumental tests on Xiaomi Mi box 3. Decoding string looks 1.9s using kxSerialization and 53ms using Moshi. It is huge difference in performance. I also tested it on Sony Bravia 4k 2015 and results are same.
To Reproduce
You can find benchmark test in following archive. I also add some middle size test strings and kxSerialization is slow for them too.
SerializationBenchmark.zip
Also after decoding objects Android log reports that GC actively trying to deallocate objects.
Environment
The text was updated successfully, but these errors were encountered: