-
-
Notifications
You must be signed in to change notification settings - Fork 144
feat: Add iterator methods to Query #207
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
base: master
Are you sure you want to change the base?
Conversation
I think it'd make more sense to just implement |
I'm worried about backwards compat abd performance. Which is why I kept the existing ones for now. |
If performance is a concern, why even add this then? What's the benefit/purpose exactly? (really curious because I'm all for iterators) |
Memory consumption. As using iterators means we don't need to hold all results in memory at once. We still need to measure if it's really significantly slower or not. I'm not sure if it's really slower. But if it is, it is always possible to chunk the iteration internally so we don't transfer one by one. |
4e43908
to
ff76451
Compare
From my experience, using iterators is going to be much less efficient, because there are many JS -> C++ calls, not just one. I don't think we should make this change at all, unless there is some very specific benchmarks demonstrating that it solves a performance problem. |
Very large result sets are one reason. But we may need batching of results for this to be efficient. And benchmarks obviously. |
Add iterator methods to Query
Still need to do
capturesIter
andCapturesIterator
, typings, etc.I'm not that happy about the code duplication though... We could probably implement
matches
andcaptures
in terms ofmatchesIter
andcapturesIter
to reduce it. But that might be slower due to all the additional calls that would entail between C++ and JS, and transferring the nodes one by one.P.S.
LookaheadIterator[@@iterator]
can probably be implemented in C++, andts_query_cursor
can probably be allocated onQuery
instead of inAddonData
if we want too.Fixes #178