Use Arc instead of Box for internal expression nodes in SymbolExpr #14660
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
One or more of the following people are relevant to this code:
|
This commit updates the internal construction of the SymbolExpr struct use a reference counting pointer instead of a regular pointer to a heap allocated object. The way the binary tree gets constructed internally using a normal pointer results in a lot of a copies of elements on the tree. This creates a large performance overhead for the symbol expr as we end up copying and freeing elements on the binary tree a large amount. This was the root cause of the regression reported in Qiskit#14653 as the expression that gets generated by the transpiler internally ends up adding a lot of elements to global phase expression and that results in a lot of memory allocation and deallocation overhead. By using a reference counting pointer instead of creating and freeing copies of the expressions on the tree we instead only keep a single copy and just increment or decrement the reference count. Fixes Qiskit#14653
78283aa to
1f7619e
Compare
Pull Request Test Coverage Report for Build 15837658367Details
💛 - Coveralls |
|
Thank you for making this fix. I tried it on my mac environment with script |
| Value(Value), | ||
| Unary { | ||
| op: UnaryOp, | ||
| expr: Box<SymbolExpr>, | ||
| expr: Arc<SymbolExpr>, | ||
| }, | ||
| Binary { |
There was a problem hiding this comment.
At least for Expr, I put expression variants with multiple inner Exprs within a single smart pointer, e.g. in this case:
struct Binary {
op: BinaryOp,
lhs: SymbolExpr,
rhs: SymbolExpr,
}
pub enum SymbolExpr {
Symbol(Box<String>),
Symbol(Arc<String>),
Value(Value),
Unary {
op: UnaryOp,
expr: Arc<SymbolExpr>,
},
Binary(Arc<Binary>),
}I think maybe @doichanj had this as well originally. Perhaps that could help reduce fan-out.
There was a problem hiding this comment.
Yeah lets save this for a potential follow up PR. I was thinking this should be backported for a 2.1.1 and I would like to keep the diff minimal for the backport. I think adding a struct like you're proposing and using a single pointer like you're proposing is nice change.
kevinhartman
approved these changes
Jun 24, 2025
mergify bot
pushed a commit
that referenced
this pull request
Jun 25, 2025
…14660) This commit updates the internal construction of the SymbolExpr struct use a reference counting pointer instead of a regular pointer to a heap allocated object. The way the binary tree gets constructed internally using a normal pointer results in a lot of a copies of elements on the tree. This creates a large performance overhead for the symbol expr as we end up copying and freeing elements on the binary tree a large amount. This was the root cause of the regression reported in #14653 as the expression that gets generated by the transpiler internally ends up adding a lot of elements to global phase expression and that results in a lot of memory allocation and deallocation overhead. By using a reference counting pointer instead of creating and freeing copies of the expressions on the tree we instead only keep a single copy and just increment or decrement the reference count. Fixes #14653 (cherry picked from commit 3b26002)
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 25, 2025
…14660) (#14665) This commit updates the internal construction of the SymbolExpr struct use a reference counting pointer instead of a regular pointer to a heap allocated object. The way the binary tree gets constructed internally using a normal pointer results in a lot of a copies of elements on the tree. This creates a large performance overhead for the symbol expr as we end up copying and freeing elements on the binary tree a large amount. This was the root cause of the regression reported in #14653 as the expression that gets generated by the transpiler internally ends up adding a lot of elements to global phase expression and that results in a lot of memory allocation and deallocation overhead. By using a reference counting pointer instead of creating and freeing copies of the expressions on the tree we instead only keep a single copy and just increment or decrement the reference count. Fixes #14653 (cherry picked from commit 3b26002) Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This commit updates the internal construction of the SymbolExpr struct use a reference counting pointer instead of a regular pointer to a heap allocated object. The way the binary tree gets constructed internally using a normal pointer results in a lot of a copies of elements on the tree. This creates a large performance overhead for the symbol expr as we end up copying and freeing elements on the binary tree a large amount. This was the root cause of the regression reported in #14653 as the expression that gets generated by the transpiler internally ends up adding a lot of elements to global phase expression and that results in a lot of memory allocation and deallocation overhead. By using a reference counting pointer instead of creating and freeing copies of the expressions on the tree we instead only keep a single copy and just increment or decrement the reference count.
Details and comments
Fixes #14653