The fix for SERVER-27209 removed a BSONElement constructor taking CachedSizeTag. However, while the constructor that we're using in its place allows specifying both the name length and the value length, it also allows replacing either argument by -1. This is suboptimal, as it requires checks for this magic value in the very hot path of constructing BSONElement values.

The effect is a 12% drop in performance of validateBSON, as shown in the bson_bm benchmark regressing from 4.25GB/sec to 3.75 GB/sec. We should fix this either by reinstating the CachedSizeTag constructor, or (preferably, IMO) removing the special -1 uses for construction of elements. If we'd want these, using a special constructor for each of those would be reasonable. Call sites should always know whether they're defaulting either argument, so there really is no justification for much more fragile and slow run-time checks.