Verify that ForestDB store's allDocs query is actually faster than SQLite store's allDocs

[zgramana]

Hideki has some evidence that suggests CBForest's iteration on allDocs query is actually slower than SQLite's.

[snej]

Hideki and I went over this last month. allDocs iteration on iOS is extremely fast, both in CBL/iOS and with the CBForest C API. It must be something related to the JNI glue that makes it slow.

[borrrden]

I was in on this meeting as well, it's not the fact that Java is slower than CBForest, but we want to know if SQLite on iOS is faster or slower than ForestDB on iOS for the allDocs query.

[snej]

OK, I can rig up a comparative test for that.

[snej]

tl;dr: allDocs looks to be exactly the same speed with ForestDB vs SQLite, on iOS.

I modified a WorkerBee test and looked at allDocs time for ForestDB and SQLite on my iPhone 6+. The code being benchmarked is:

    CBLQuery* query = [self.database createAllDocumentsQuery];
    query.allDocsMode = kCBLIncludeDeleted;
    CBLQueryEnumerator* rowEnum = [query run: &error];
    for (CBLQueryRow* row in rowEnum) {
        @autoreleasepool {
            key = row.key;
            value = row.value;
        }
    }

(I don't know why Ashvinder left the includeDeleted flag on, but it shouldn't make a difference in timing since the db contains no deleted docs.)

With a database of 10000 docs, 1000 bytes each, SQLite and ForestDB each took 154ms.
With 100 docs, 100000 bytes each, SQLite and ForestDB each took 1.3ms.

In other words, each storage engine takes on the order of 10µs per document, scaling up slightly as the number of docs increases.

(I profiled this in Instruments, and significantly less than half the time is spent in CBForest; the rest is Obj-C overhead and allocating CBL objects. So the CBForest C API should be faster than this.)