If you’re not actually rendering anything, why put that code inside a react component?
I eliminated rendering simply for the purpose of comparison between with and without getMeteorData.
From further testing it seems the bottleneck is the reverse sort, presumably because minimongo doesn’t have indexes. But the fact that a collection with only a hundred or so entries entries takes a second to return the most recent <n> entries (for any value of <n> ) is alarming.
Rendering a sorted subset of a collection seems like a pretty common operation, so my default assumption is it’s something I’m doing wrong.
1 Like
I think this is actually just a case of Minimongo being slow. I guess Blaze uses observe under the hood to avoid re-running queries. I wonder if there is something we could do to make the same thing happen in any autorun - so basically, when you get a cursor from mongo, Tracker could cache that cursor, and use an observe internally to fire changes on that query rather than rerunning it every time.
Edit:
I think a proof of concept for this could be implemented in a package, simply by making a wrapper function for a cursor.
5 Likes
@sashko i know you’ve had your hands full, but are you aware of any progress in this direction or this a bit of dead end at this point?
3 Likes
Everything by meteor is slowly dying need to switch to open wide pacakges (redux) will fit