Skip to content
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

"Complex Load" does not make much sense #16

Open
greenrobot opened this issue Jul 12, 2016 · 0 comments

Comments

Projects
None yet
1 participant
@greenrobot
Copy link
Contributor

commented Jul 12, 2016

The tests for "load" in the "complex trial", loads 50 address books and then walks along the relations potentially resolving them on the fly (doing database requests). I had a closer look why DbFlow takes just a few milliseconds (usually single digit) while all others take hundred of milliseconds. I think the test set up is questionable: after inserting the entities, they stay around in memory initialized with all relations already set up for DbFlow. So what happens is that DbFlow makes a single query and is done, while others must hit the database multiple times. So you test rather caching than loading. I could send a trivial PR for greenDAO in order to make the same caching work, which would also result in single digit ms test runs.

However, I'd rather propose to clear all caches before doing the complex load test to actually benchmark loading. For greenDAO, you can clear the memory "cache" using daoSession.clear(). I don't did not find the equivalent in DbFlow, so I could not try myself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.