Are there any tricks to optimizing loading from SQ...
# apollo-kotlin
w
Are there any tricks to optimizing loading from SQL cache? In debug loading from the cache is very slow (~2 seconds for a list of 20 objects). Faster in release of course, but I have a feeling something can be done. Do you see visible delays when loading data from cache?
Sample flame chart, just for reference. The left-hand
selectRecordForKey
is ~500ms
t
In my old company we were using it but we were loading quite a big query. And it was always slow. Since it is in background we didn't mind that much
w
same call
@taso Thanks! It’s in background but if it’s rather slow I’m thinking if we need to preload it before user actually opens the screen, otherwise they see loading indicator even though the data should be there 😕 I wanted to check if perhaps I can speed things up without that overhead first 🙂
m
For what it's worth, I'm looking into this for 3.0: https://github.com/apollographql/apollo-android/pull/2863
That should speed up the process by a few percent but I don't expect an order of magnitude of improvement given that most of the time is spent executing the SQL queries
Another thing we could do is "batch" SQL queries. It's not super easy though because we don't know the cache ids in advance so we'd have to do something like breadth-first traverse the model tree, run all SQL queries and then reconstruct the tree
w
Thanks 🙂 The batching queries is interesting, I understand it wouldn’t be any simpler for lists either? I’m curious about the
readList
that’s taking a big chunk of time on the second graph, it seems to be the slowest bit
m
Reading all cache references in a list can actually be parallelize relatively easily I think
The "relative" is compared to parallelizing references in objects
Overall, the whole thing is not straightfoward and there's a bunch of cleanup that needs to happen first
w
Got it. I don’t have much spare time, but if at any point there’s a clear direction how this can happen I could try implementing it 🙂
👍 1