You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the Async LINQ queries to do not support the OrderBy(...) operator. You have to first call ToListAsync() and then sort the results in memory (using the regular LINQ-To-Object OrderBy(...).ToList().
The main issue with this operator, is that it must first buffer all the results in memory, before being able to sort them (the last one would be the first result once sorted). And then when the sorting is done, it will output all the results in burst. In effect, the first call to MoveNext() will take a very long time (99% of the query time), and then all successive MoveNext() calls will be instant and non-async (they will simply return the next item in an array).
As long as people use this as the last step in a query, with low item count, or with very selective Where(...) clauses in front, this should be OK.
Anyway, there does not seem to be any magical solution around this problem, and I hope that users of the API will think about what they do before doing something like tr.GetRange(subspaceWith10MillionKeys.ToRange()).OrderBy(kvp => ...).Take(10).ToListAsync() (which would need to read all 10 million keys, sort them all in memory, and then only take the first 10.
The text was updated successfully, but these errors were encountered:
Currently, the Async LINQ queries to do not support the OrderBy(...) operator. You have to first call
ToListAsync()
and then sort the results in memory (using the regular LINQ-To-ObjectOrderBy(...).ToList()
.The main issue with this operator, is that it must first buffer all the results in memory, before being able to sort them (the last one would be the first result once sorted). And then when the sorting is done, it will output all the results in burst. In effect, the first call to
MoveNext()
will take a very long time (99% of the query time), and then all successiveMoveNext()
calls will be instant and non-async (they will simply return the next item in an array).As long as people use this as the last step in a query, with low item count, or with very selective
Where(...)
clauses in front, this should be OK.Anyway, there does not seem to be any magical solution around this problem, and I hope that users of the API will think about what they do before doing something like
tr.GetRange(subspaceWith10MillionKeys.ToRange()).OrderBy(kvp => ...).Take(10).ToListAsync()
(which would need to read all 10 million keys, sort them all in memory, and then only take the first 10.The text was updated successfully, but these errors were encountered: