Conversation
- sink params consume the Block at each call boundary, reducing concurrent copies from ~4 to 1 - Explicit body reset in validateBlock frees seq[Transaction] immediately after persistence, not when GC collects the async frame - Closure handler nil-out in processQueue breaks the reference chain from the queue item to the captured Block - move at the fetch site clears the source blocks[n] immediately
Comparing
|
| parentBlk: BlockRef, | ||
| txFrame: CoreDbTxRef, | ||
| blk: Block, | ||
| blk: sink Block, |
There was a problem hiding this comment.
Why use sink here? Block is a stack variable so shouldn't effect the heap memory usage.
| # per-arena free-lists by default; without this, RSS doesn't shrink after | ||
| # disposed frames are reclaimed. | ||
| proc mallocTrim(pad: csize_t): cint {.importc: "malloc_trim", header: "<malloc.h>".} | ||
|
|
There was a problem hiding this comment.
Since this is not available on MacOS or windows, does this fix work on those platforms? Or does it depend on using malloc_trim?
There was a problem hiding this comment.
the rss memory does shrink if there's memory pressure - there's no need for this kind of trimming generally, ie RSS is not that relevant
| var memAfter = 0 | ||
| if c.persistedCount > 0: | ||
| memBefore = getOccupiedMem() | ||
| GC_fullCollect() |
There was a problem hiding this comment.
we want to avoid gc_fullcollect as much as possible as it is very expensive..
The way to get rid of sawtooth is to find reference cycles and explicitly break these with = nil - what gc_fullcollect does is essentially to collect cycles - the sawtooth happens because the cycle collector runs rarely (and it runs rarely because it's very very slow)
3 participants
Attempt to fix the sawtooth nature of the memory graph