-
-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow(ish) read/deserialization performance #133
Comments
Excellent work and thank your taking your time to investigate this. Honestly, I have not paid attention to the performance to this detail. During your testing did you profile it to see what is the hot spot? My initial guess is here - inner = mapper.asObject(document.get("inner", Document.class), IMappable.class); |
Thank you for your response. No, I didn't profile the benchmark code. |
Running a few thread-dumps (without actually profiling the code) - it seems like it's a matter of reflection construction - using fixed/concrete constructors - the benchmarks went from 3000 us to 30! This means that if you implement a reflective constructor cache in the AbstractMapper you could Drastically improve read performance !!! However, this seems like a bug related to the |
Excellent investigation. I'll come up with a fix soon. |
Can you run the same benchmark on the latest snapshot 3.2.0-SNAPSHOT now? |
Could you publish a snapshot to maven central (or some staging repo)? BTW - I think you should also update your |
It is already deployed in snapshot repository - https://oss.sonatype.org/content/repositories/snapshots/org/dizitart/nitrite/ But I didn't understand what do you mean by overriding |
I'm wondering how i works in comparison with https://www.objectdb.com/ ObjectDB is a killer of H2, and Nitrite is using H2 storage engine, so this might be interesting comparison |
Hello
I've create a JMH benchmark to test Nitrite random read performance.
I insert a varying amount of entities into an in-memory only nitrite
ObjectRepository
and then query it using an indexed field with a varying degree of dispersion/randomness.All entities are of a single types that implements
Mappable
While searching the database using the index takes a few microseconds, which is great, deserializing the result set (a few dozens of entities) takes a few milliseconds. which is 3 orders of magnitude slower.
Is it possible to improve upon these numbers with nitrite?
Results (numbers are microseconds per operation (us/op) ):
Here's the benchmark code (uses JMH and Lombok annotations):
The text was updated successfully, but these errors were encountered: