I've had an initial look at this and have been unable to reproduce the slower throughput locally. In my local testing with 10,000,000 1KB documents master is faster than mad-hatter. I have a hunch that the dataset that we are generating is not valid JSON so master is spending longer printing log lines informing us that each and every document is invalid (I've taken a dive into the perfrunner code to check, but I'm not 100% sure yet). It would be helpful if we had the backup logs for our successful runs, however, we don't keep them.

After further looking into this and speaking to Patrick Varley, this drop in throughput makes sense since we are now having to parse each document to insert the scope/collection into the document JSON; this is similar to the drop in performance which we saw for cbimport when we added the '--include-key' flag. With this said, there might be ways which we could improve the throughput such as:
1) Changing the concurrency model to handle the JSON marshaling/un-marshaling in s separate goroutine that doesn't block.
2) Adopting a "pay for what you use model" e.g. we avoid having the performance drop for users that don't use collections.

Marking as 'Not a Bug' and closing since drop in performance makes sense since the collection aware cbexport is slightly more expensive since we need to encode scope/collection names into the exported JSON meaning we are handling the JSON more than we were previously.