The performance pain
Currently, the use of lpAssertValidEntry can cost 10% of CPU time.
Description of the performance issue
The lpAssertValidEntry function was added to ensure the validity of the data. The issue behavior was reproduced by lifting the deep_sanitization checks and placing the corrupted data directly into the server.
The call is costly since it sits on the Critical Path of the listpack's First, Next, Prev functions and therefore has a significant impact that should be addressed.
Alternatives you've considered
- Keep the current behavior and validate the data on each step.
- Change the assert to a
debugAssert which will run only in debug mode.
- Run the assert periodically. For example, run it once every 256 calls. This will keep some level of sanitization at a minimal cost.
- Not have one behavior but introduce a server parameter that will specify the protection level.
Additional information
@filipecosta90 is working on retrieving precise statistics on the impact of the lpAssertValidEntry function.
Related to #11273 where testing for the validity of the listpack was moved from the READ functions to the WRITE function.
The performance pain
Currently, the use of
lpAssertValidEntrycan cost 10% of CPU time.Description of the performance issue
The
lpAssertValidEntryfunction was added to ensure the validity of the data. The issue behavior was reproduced by lifting thedeep_sanitizationchecks and placing the corrupted data directly into the server.The call is costly since it sits on the Critical Path of the listpack's
First, Next, Prevfunctions and therefore has a significant impact that should be addressed.Alternatives you've considered
debugAssertwhich will run only in debug mode.Additional information
@filipecosta90 is working on retrieving precise statistics on the impact of the
lpAssertValidEntryfunction.Related to #11273 where testing for the validity of the listpack was moved from the READ functions to the WRITE function.