[SERVER-22403] Clean up dynamic_cast's in pipeline directory Created: 01/Feb/16  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Aggregation Framework, Internal Code
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Charlie Swanson Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 0
Labels: optimization, storch
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-27309 Replace dynamic_cast calls where poss... Closed
Assigned Teams:
Query Optimization
Backwards Compatibility: Fully Compatible
Participants:

 Description   

We often use dynamic_cast when we really want to check if something is an exact type. dynamic_cast is unnecessarily expensive for this use, and we should use typeid instead.

For example, we could create a helper as follows:

template <TargetClass>
bool exactDynamicCast(void* srcObj) {
    return typeid(TargetClass) == typeid(*srcObj);
}



 Comments   
Comment by James Wahlin [ 07/Dec/16 ]

The worst offenders in profiling dynamic_cast use for $lookup are:

  1. PipelineD::prepareCursorSource
  2. Pipeline::ensureAllStagesAreInLegalPositions
Comment by Charlie Swanson [ 07/Dec/16 ]

Moving back into Needs Triage based on james.wahlin's recent performance work in the linked SERVER-27309.

Comment by Andy Schwerin [ 01/Feb/16 ]

You would be well advised to get out of type checking entirely. It would be better to add a property to the base class that you can interrogate, focused on the actual thing you care about. I suspect the exact type match stands in for some such property.

Comment by Adam Midvidy [ 01/Feb/16 ]

can you use checked_cast?

Generated at Thu Feb 08 04:00:18 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.