Is it possible to schedule this improvement for an upcoming release?

This should give me a serious performance boost. Especially in a sharded setup.

This is important to me, as it will significantly improve performance on my machine (I'm cpu bound on a single core, on a 8 core server).

Would be good to have I think for sharded setups; given I think group() does not work when sharded for example either?

I'm surprised this is listed as "planned but not scheduled". Won't this be fixed as part of moving to v8 in 2.4?

The move to V8 does enable additional multi-threading options, but MapReduce itself needs some restructuring to take advantage of this properly. This won't be fully realized for 2.4, but it should probably be placed on the schedule and not left as "planned but not scheduled".

To clarify a bit further, v2.4 will allow multiple MapReduce commands to execute JavaScript concurrently. A single MapReduce command will only use one core.

Hum, so instead of 1 M/R at a time we could do "numCPU" M/R? I would prefer that my M/R become faster. Why they will still use only one CPU? When you perform a big M/R there is in fact a lot of M/R, they should be parallelized no? Or maybe I miss something..

I think there is agreement that M/R should use multiple cores. It's just a question of fixing it to do that now that we have v8.

Hi Antoine,

The goal of this ticket is to allow a single MapReduce job to use multiple cores, which is not yet implemented. This requires several new features; e.g. a storage system for intermediate results that doesn't acquire a db-level write lock, and global CPU/memory resource management.