GC: optimize alloc of small object by keeping track of unused pages#2524
GC: optimize alloc of small object by keeping track of unused pages#2524dlang-bot merged 1 commit intodlang:masterfrom
Conversation
|
Thanks for your pull request, @rainers! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub fetch digger
dub run digger -- build "master + druntime#2524" |
| uint* bPageOffsets; | ||
|
|
||
| // The small object pool uses the same array to keep a chain of pages with the same | ||
| // bin size and free pages (searchStart is first free page) |
There was a problem hiding this comment.
This comment is a bit premature, but keeping track of pages with the same bin size will be needed for deferring incremental recover into later allocations.
|
Rainer on fire ;) - the GC improvements are impressive (and at the same time kinda shocking that so much potential hasn't been exploited yet). |
|
@rainers rebasing to master should fix the CircleCI build. |
rainers
force-pushed
the
opt_alloc
branch
2 times, most recently
from
4ee6b28 to
20a3788
Compare
BTW: time drops to about 5 seconds when compiling with LDC! |
|
Is that so surprising? 30-40% runtime reduction with LDC seems like a rough rule of thumb for general code (probably more for number-crunching code), e.g., DMD itself. |
|
Not really surprising, though profiling suggested that marking is pretty much memory bandwidth limited (most of the samples were taken at the instruction reading the scanned memory). LDC compiled marking code was better similar to the overall ratio which hints that there is still more leeway for improvement. |
|
[@rainers: Just as a reminder, |
Doesn't make a notable difference. The parser doesn't create many temporary objects AFAICT. |
5 participants
This simple change is what yields the larger time difference of #2520 (comment), i.e. reduces execution time of the vdparser-test from approx. 10.5 s to 7.5 s.