Ruben Verborgh

Node streams for objects come with a terrible performance bottleneck (see for instance RubenVerborgh/N3.js#6), but iteration by itself would makes sense. However, there is a performance penalty associated with crossing...

…but it would make sense to implement a JavaScript-land iterator interface on top of the limit/offset system, for instance such that triples are fetched in groups of 100.

Not bad, not bad at all… I wonder how much better RubenVerborgh/AsyncIterator performs on that. Native iterators are to be tested as well, definitely. In any case, a more than...

> Adding a pause and resume function to the c code, that stops/resumes the iterator. > Sending each statement via a callback to nodejs I wouldn't do that, you want...

We probably should have an optional `bufferSize` parameter with a sensible default. Maybe 1024 or so is more sensible than 100 (but for TPF I'd like to set it to...

> To me, it seems that implementing this in batches (all on the js side) comes at a cost. Yes, but everything depends on the access pattern! What if only...

Also, the `?s ?o` pattern is a very exotic one, you won't see it in a lot of SPARQL queries (and if you do, it is unlikely to be the...

> What is your usecase only fetching the first 10 results? If you know you're interested in 10, you can just use the callback mechanism and add a limit of...

> That's right, but guess we have to find a middle-ground between memory usage and performance here. And a buffer of 1024 still sounds reasonable right? +1 > Good point....

So we might even need to treat the `` case differently from the others then. Regarding pivot point, it would be good to set up an experiment to determine this,...