Skip to content

Commit 19ef2be

Browse files
committed
fix #937
1 parent 30e8b81 commit 19ef2be

File tree

1 file changed

+13
-8
lines changed

1 file changed

+13
-8
lines changed

docs/guide/querying.rst

Lines changed: 13 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -340,14 +340,19 @@ Javascript code that is executed on the database server.
340340

341341
Counting results
342342
----------------
343-
Just as with limiting and skipping results, there is a method on
344-
:class:`~mongoengine.queryset.QuerySet` objects --
345-
:meth:`~mongoengine.queryset.QuerySet.count`, but there is also a more Pythonic
346-
way of achieving this::
347-
348-
num_users = len(User.objects)
349-
350-
Even if len() is the Pythonic way of counting results, keep in mind that if you concerned about performance, :meth:`~mongoengine.queryset.QuerySet.count` is the way to go since it only execute a server side count query, while len() retrieves the results, places them in cache, and finally counts them. If we compare the performance of the two operations, len() is much slower than :meth:`~mongoengine.queryset.QuerySet.count`.
343+
Just as with limiting and skipping results, there is a method on a
344+
:class:`~mongoengine.queryset.QuerySet` object --
345+
:meth:`~mongoengine.queryset.QuerySet.count`::
346+
347+
num_users = User.objects.count()
348+
349+
You could technically use ``len(User.objects)`` to get the same result, but it
350+
would be significantly slower than :meth:`~mongoengine.queryset.QuerySet.count`.
351+
When you execute a server-side count query, you let MongoDB do the heavy
352+
lifting and you receive a single integer over the wire. Meanwhile, len()
353+
retrieves all the results, places them in a local cache, and finally counts
354+
them. If we compare the performance of the two operations, len() is much slower
355+
than :meth:`~mongoengine.queryset.QuerySet.count`.
351356

352357
Further aggregation
353358
-------------------

0 commit comments

Comments
 (0)