Something is very wrong with PouchDB views when run on JXcore

[yaronyg]

We use the identical code to run in WebViews and on desktop and perf is fine. But specifically on JXcore on the phone perf collapses. See thaliproject/leveldown-mobile#4 for details.

@enricogior Please run the tests with spidermonkey with JIT on desktop just to see if the issue is specific to PouchDB on SpiderMonkey.

[enricogior]

Test results on desktop using leveldown-mobile and 2000 docs:

 - node    1.4s
 - jx V8   2.2s
 - jx SM  17.4s

Clearly there is something wrong when running PouchDB using SpiderMonkey.
That can't simply be the SM vs V8 performance diff, since we never saw such a difference.

Results using memdown and 2000 docs:

 - jx V8   2.0s
 - jx SM  21.2s

That is consistent with what we saw on Android.

Interesting thing: on desktop SM with JIT disabled is faster, it takes 15.5s vs 21.2s with JIT enabled.
While adding the data is faster with JIT enabled.

[enricogior]

Test results on desktop using 2000 docs:

 - node    1.4s
 - jx V8   2.2s
 - jx SM  17.4s

Clearly there is something wrong when running PouchDB using SpiderMonkey.
Tha can't simply be the SM vs V8 performance diff, since we never saw such a difference, usually it's under 20%.

[yaronyg]

What we are seeing right now is that the GC goes bananas when we run views so something went wrong in the GC. We are still investigating.

[enricogior]

Disabling the GC makes the test 5 times faster. That is still 2.5 times slower than V8, but there are some memory allocation related functions that have a very high CPU time usage: fetchNextDecommittedArena() takes 33% of the CPU time by itself, but it may a side effect of disabling part of the GC (the GC is not a plug&play component that can simply be disabled, it's too tied into the memory allocation functions).

Some interesting data regarding the memory usage under V8 and SM:

• with V8 the test goes up to 300MB of memory in use
• with SM with the GC enabled it doesn't pass 95MB
• with SM with the GC disabled it goes up to 600MB

It looks like the SM's GC is more aggressive compared to V8's GC.
We need to look into the GC code to check if there are parameters tat can be triggered to have a less aggressive behavior.

[enricogior]

The evalFunctionInVm() function in PouchDB triggers the SpiderMonkey's GC craziness in JXcore.

https://github.com/pouchdb/pouchdb/blob/master/packages/node_modules/pouchdb-mapreduce/src/evalFunctionInVm.js

Since in our test there isn't a view user defined function, I replaced the code that invokes evalFunctionInVm with a direct call to the function that inserts the records in the view.

https://github.com/pouchdb/pouchdb/blob/master/packages/node_modules/pouchdb-mapreduce/src/index.js#L520
https://github.com/pouchdb/pouchdb/blob/master/packages/node_modules/pouchdb-mapreduce/src/index.js#L477

where view.mapFun is

function mapFun(doc) {
                    if (doc.title) {
                        emit(doc.title);
                    }
                }

That in turns does a trivial:

   var output = {id: doc._id, key: normalizeKey(doc)};
   mapResults.push(output);

The result is that the tests is 20 times faster and completes the query in 1.2s, still slower than V8 (0.5s) but acceptable.

[yaronyg]

For now we want to see if it isn't easier to get a mode in PouchDB that lets us run views outside of the sandbox. We have tested and that does fix the perf problem and since it's our view on our database we don't need the sandbox security.