-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Avoid parsing X triggers if the filter is empty #3083
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid parsing X triggers if the filter is empty #3083
Conversation
When a filter is empty, it means it cannot match anything. By guarding the parsing of the triggers upfront, we avoid looping through lot's of element in the blocks, this is especially true for full blocks that contain all the transactions. Fixes #3080
When a filter is empty, it means it cannot match anything. By guarding the parsing of the triggers upfront, we avoid looping through lot's of element in the blocks, this is especially true for full blocks that contain all the transactions. Remove a `clone()` that can be delayed to later at the same time. Fixes #3080
b487634 to
b884cf9
Compare
| } | ||
| } | ||
|
|
||
| impl From<&EthereumBlockFilter> for EthereumCallFilter { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally if a From<&T> impl is effectively cloning T internally as this is doing, I prefer having only the From<T> impl and requiring the caller to clone if they want to use it on an &T, to make the potential cost of cloning explicit.
Feel free to merge after addressing this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not exact that it's cloning T directly, it's actually cloning only what is required for the transformation to work. I don't see why cloning EthereumBlockFilter would be necessary when we only care about some parts of the actual EthereumBlockFilter struct. The overprice is not quite big here, but still present. We have other occurrences of this pattern in other location like BlockPtr::From<&EthereumBlock>.
I do understand the concern about the implicit "copy", but any From<> calls does some kind of allocation, so it's already implied there is some allocations cost when dealing with From<> calls.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True that this can be implemented more efficiently on &T since it only clones the necessary bits, but it does pessimize the implementation for T since that now clones when previously it moved the addresses. Is From< EthereumBlockFilter> even used anywhere? If not we can just remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I see the point about the other version being now less efficient. I removed it and every places now uses the reference version.
…EthereumCallFilter`
When a filter is empty, it means it cannot match anything. By guarding the parsing of the triggers upfront, we avoid looping through lot's of element in the blocks, this is especially true for full blocks that contain all the transactions. Remove a `clone()` that can be delayed to later at the same time. Fixes #3080
When a filter is empty, it means it cannot match anything. By guarding the parsing of the triggers upfront, we avoid looping through lot's of element in the blocks, this is especially true for full blocks that contain all the transactions. Remove a `clone()` that can be delayed to later at the same time. Fixes #3080
When a filter is empty, it means it cannot match anything. By guarding the parsing of the triggers upfront, we avoid looping through lot's of element in the blocks, this is especially true for full blocks that contain all the transactions.
Fixes #3080