This ticket is a spinoff from SERVER-20876 to investigate the underlying issue that index lookups become slower after removing documents from a collection. See this comment for more details and a repro, but in summary the test

1. creates an empty collection and index and does queries using that index
2. inserts some number of documents into the collection
3. removes all documents from the collection, leaving collection and index empty again
4. repeats the same queries using the again empty index, which are observed to be significantly slower than the queries in step 1 on the new index and collection

Referring to the stack trace in the referenced comment, the underlying cause seems to be slow WT search_near operations requiring tree walks, even though the table should be empty.

The impact on user-level operations depends on the amount of overhead before getting to the WT layer in the path by which the query is done, but in the particular repro referenced above, declines of 15-50% were seen, depending on the number of documents inserted then removed. That path has a fair amount of overhead outside WT, so impact could be substantially higher if there are operations that do repeated lookups with low code path overhead outside WT.