Am Samstag, 12. April 2008 02:27 schrieb chromatic: > I've committed a couple of minor optimizations which speed up Rakudo and > Perl OO in general by about 35%. There may be a few more lurking, but I > keep running into three spots which dominate most of the other optimization > strategies I might pursue. > > 1) The Garbage Collector is algorithmically inefficient. There are various > potential optimization strategies here which don't require us walking every > allocated header in the system multiple times (yes, it's that bad in at > least two places),
Last time I looked at it, a header isn't "walked" if the live bit is already set. pobject_lives() will be called, yes, but that was a macro in very former times and cheap for the common case, when the live bit is already set. > but the real solution I suspect is to replace the > current GC with at least the one specified in the new GC PDD. Which pdd are you refering to? I don't see any substantial text in pdd09_gc.pod. > The two worst spots are turning off the live flag (and destroying > everything with a custom destroy flag) and dividing newly-allocated memory > pools into headers and manually adding each header to a linked-list of free > objects. A bitmap handling for live flags was in the code base ~1.5 yrs ago. You could look at svn diffs near: r14799 | leo | 2006-09-30 12:38:35 +0200 (Sa, 30 Sep 2006) | 4 lines r14798 | leo | 2006-09-30 11:24:49 +0200 (Sa, 30 Sep 2006) | 6 lines [GC] remove ARENA_DOD_FLAGS code I've removed it, because I couldn't measure any remarkable performance improvements. > Flag marking would be much cheaper (and likely cache-friendlier, though I > haven't done the math to make sure of this) See above. > The free object list is the reason that compacting/copying collectors are > popular, [ ... ] Copying collectors need another indirection in PMC allocation, as a PMC isn't allowed to move - external C code might have stored a pointer to a PMC. Did this philosophy change somewhen? Anyway, due to better cache locality and in combination with diffently sized PMCs a copying collector could be faster I'd estimate. > With that all said, one good optimization is to allocate fewer PObjs Indeed. > -- c leo
