reuse VertexRef instance on update #3444
Merged
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
When updates to the MPT happen, a new VertexRef is allocated every time - this keeps the code simple but has the significant downside that updates cause unnecessary allocations. Instead of allocating a new `VertexRef` on every update, we can update the existing one provided that it is not shared. We can prevent it from being shared by copying it eagerly when it's added to the layer. A downside of this approach is that we also have to make a copy when invalidating hash keys, which affects branch and account nodes mainly. The tradeoff seems well worth it though, specially for imports that clock a nice perf boost, like in this little test: ``` (21005462, 21008193] 14.46 15.50 2,479.35 2,656.98 9m26s 8m48s 7.16% 7.16% -6.69% (21013654, 21016385] 15.28 16.14 2,523.74 2,665.83 8m56s 8m27s 5.63% 5.63% -5.33% (21021846, 21024577] 15.52 17.66 2,539.25 2,889.61 8m47s 7m43s 13.80% 13.80% -12.12% blocks: 16384, baseline: 27m10s, contender: 24m59s Time (total): -2m10s, -8.00% ```
arnetheduck
added a commit
that referenced
this pull request
Jul 3, 2025
Deferred GC seemed like a good idea to reduce the amount of work done during block processing, but a side effect of this is that more memory ends up being allocated in certain workloads which in turn causes an overall slowdown, with a long test showing a net performance effect that hovers around 0% and more memory usage. In particular, the troublesome range around 2M sees a 10-15% slowdown and an ugly memory usage spike. Reverting for now - it might be worth revisiting in the future under different memory allocation patters, but as usual, it's better to not do work at all (like in #3444) than to do work faster. This reverts commit 3a00915.
arnetheduck
added a commit
that referenced
this pull request
Jul 4, 2025
Deferred GC seemed like a good idea to reduce the amount of work done during block processing, but a side effect of this is that more memory ends up being allocated in certain workloads which in turn causes an overall slowdown, with a long test showing a net performance effect that hovers around 0% and more memory usage. In particular, the troublesome range around 2M sees a 10-15% slowdown and an ugly memory usage spike. Reverting for now - it might be worth revisiting in the future under different memory allocation patters, but as usual, it's better to not do work at all (like in #3444) than to do work faster. This reverts commit 3a00915.
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.
When updates to the MPT happen, a new VertexRef is allocated every time - this keeps the code simple but has the significant downside that updates cause unnecessary allocations.
Instead of allocating a new
VertexRefon every update, we can update the existing one provided that it is not shared. We can prevent it from being shared by copying it eagerly when it's added to the layer. A downside of this approach is that we also have to make a copy when invalidating hash keys, which affects branch nodes mainly.The tradeoff seems well worth it though, specially for imports that clock a nice perf boost, like in this little test: