A serial implementation of the query phase for large document collections requires careful thought and planning. Since a single, multi-user machine has finite memory and swap space, projecting a query into the term-document space must use as little memory as possible while executing as efficiently as possible. Any operation that depends on the size of the document collection must be performed incrementally, without loading large sections of the collection into memory. Objects that are no longer needed must be reused or discarded to keep memory usage as low as possible.
The time required to perform the query phase increases in proportion to the number of terms and documents in the database (see [18]). The query phase consists of a small amount of bookkeeping (adding terms and documents to the query, keeping track of the terms actually used in the query, etc.) and a large amount of computation as the query is matched against each term or document vector. In practice, the bookkeeping costs are fairly low since they depend on the size of the query instead of the number of terms and documents in the collection. Typically, matching costs far exceed the bookkeeping costs.
An efficient serial implementation of the query phase should vector as it is needed, performing all the computation that involves that vector, and then discard the vector, freeing memory for the next vector. Since only one vector is kept in memory at a time, the amount of memory required does not increase with the number of terms and documents in the database. Also, this pipeline is fairly time-efficient since the algorithm accesses contiguous vectors, and some I/O buffering is performed at the operating system level.