Skip to content

defer gc during block processing#3384

Merged
arnetheduck merged 1 commit intomasterfrom
less-gc
Jun 20, 2025
Merged

defer gc during block processing#3384
arnetheduck merged 1 commit intomasterfrom
less-gc

Conversation

@arnetheduck
Copy link
Copy Markdown
Member

During block processing, we allocate lots and lots of small objects (VertexRef and friends) which causes overhead as the GC is run without much benefit - this can be up to 15% of CPU time during block import when running with a large vertex cache.

During block processing, we allocate lots and lots of small objects
(VertexRef and friends) which causes overhead as the GC is run without
much benefit - this can be up to 15% of CPU time during block import
when running with a large vertex cache.
@arnetheduck arnetheduck merged commit 3a00915 into master Jun 20, 2025
@arnetheduck arnetheduck deleted the less-gc branch June 20, 2025 07:59
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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant