[SERVER-67028] Fix 12% perf loss in validateBSON due to BSONElement changes Created: 05/Jun/22  Updated: 27/Oct/23  Resolved: 09/Jun/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Geert Bosch Assignee: Geert Bosch
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
is caused by SERVER-27209 BSONObj::getStringField() does not ha... Closed
Sprint: Execution Team 2022-07-11
Participants:

 Description   

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.



 Comments   
Comment by Geert Bosch [ 09/Jun/22 ]

It turns out that the performance change was solely due to the compiler inlining things differently. So, not something we need to worry about right now.

Generated at Thu Feb 08 06:07:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.