We should take a close look at the driver's performance benchmark results and look for opportunities to improve. As an example, some of the things observed while running the large doc bulk insert benchmark:

• Use of java.util.Stack in BsonWriter implementations. All the methods of this class are synchronized, which is unnecessary in non-thread safe classes. Could use ArrayDeque instead.
• Lots of calls to CodecRegistry#get in DocumentCodec#writeValue and {BsonDocumentCodec#writeValue}}. The implementation of this method in ProvidersCodecRegistry is not built for use in inner loops. Some caching within the Codec implementation could be useful here.
• ByteBufferBsonOutput is great for minimizing heap use, but there is a performance cost of all the buffer management that it has to do in an inner loop. We can consider using a simpler implementation of OutputBuffer that trades off memory use for speed. For example, we could just cache 48MB buffers instead of power-of-two buffers.

And some others:

• BsonArrayCodec should use a BsonTypeCodecMap just like BsonDocumentCodec does
• BsonArrayCodec shouldn't make a copy of its elements when decoding
• BsonDocumentCodec shouldn't make a copy of its elements when decoding
• BsonDocumentCodec should use its BsonTypeCodecMap for encoding, not just decoding
• BsonDocumentCodec _id field re-ordering could be more efficient
• Introduce valueOf methods in BsonInt32 and BsonInt64 (and use them in corresponding Codec) that are roughly equivalent to the ones in Integer and Long (which have caches for small values).

There are likely more opportunities available as well.