[SERVER-74758] SBE performance: investigate cost of invariant() and tassert() in SBE Created: 10/Mar/23  Updated: 01/Sep/23

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

Type: Improvement Priority: Major - P3
Reporter: Kevin Cherkauer Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Execution
Participants:

 Description   

There are two questions this investigation should answer:

  1. [Tactical] What is the relative performance cost of invariant() vs tassert()?
  2. [Strategic] What is the total absolute performance cost of having thousands of these calls in the production code?

Re. #1, if we find that tassert() is x% slower than invariant(), we can use that to set a goal line for improving the performance of tassert().

Re. #2, this is about finding out the maximum theoretical performance gain possible by removing 100% of the invariant() and tassert() calls, i.e.insight into how much these are costing us overall performance-wise. If this turns out to be a large number, we can use that to guide decisions on how much we want to aim to reduce the sheer numbers of these calls.



 Comments   
Comment by Kyle Suarez [ 01/Sep/23 ]

After discussion with bernard.gorman@mongodb.com we are adding this to the SBE further performance improvements epic.

Comment by Kevin Cherkauer [ 02/Aug/23 ]

Thanks steve.tarzia@mongodb.com . Note one of the things I was hoping we would learn from this investigation is what is the overall performance impact of simply the existence of all the tassert() and invariant() calls we have, i.e. how much performance we could gain if they were just removed? This would tell us the maximum theoretically possible performance gain from eliminating them, which could be used to guide decisions about how much we want to focus on converting invariant to tassert and how much we want to focus on reducing the sheer numbers of both of these in the code.

Comment by Steve Tarzia [ 02/Aug/23 ]

Ideally we would disallow new uses of invariant (and deprecated functions in general) in a clang-tidy rule or some other kind of static code analysis.  The investigation work here is a prerequisite for that.

Comment by Kevin Cherkauer [ 16/Mar/23 ]

Draft PR from Skunkworks 2023: https://github.com/10gen/mongo/pull/11172

This commented out all the invariant() and tassert() calls in most SBE code. Performance impact currently still unknown as this did not compile on ARM64 which ran the Skunkweeks benchmarks.

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