While working on a paper about allocation profiling in VMProf I got curious about how quickly the RPython GC can allocate an object. I wrote a small RPython benchmark program to get an idea of the order of magnitude.
The basic idea is to just allocate an instance in a tight loop:
class A ( object ): pass def run ( loops ): # preliminary idea, see below for i in range ( loops ): a = A () a . i = i
The RPython type inference will find out that instances of A have a single i field, which is an integer. In addition to that field, every RPython object needs one word of GC meta-information. Therefore one instance of A needs 16 bytes on a 64-bit architecture.
However, measuring like this is not good enough, because the RPython static optimizer would remove the allocation since the object isn't used. But we can confuse the escape analysis sufficiently by always keeping two instances alive at the same time:
class A ( object ): pass def run ( loops ): a = prev = None for i in range ( loops ): prev = a a = A () a . i = i print ( prev , a ) # print the instances at the end
(I confirmed that the allocation isn't being removed by looking at the C code that the RPython compiler generates from this.)
This is doing a little bit more work than needed, because of the a.i = i instance attribute write. We can also (optionally) leave the field uninitialized.
def run ( initialize_field , loops ): t1 = time . time () if initialize_field : a = prev = None for i in range ( loops ): prev = a a = A () a . i = i print ( prev , a ) # make sure always two objects are alive else : a = prev = None for i in range ( loops ): prev = a a = A () print ( prev , a ) t2 = time . time () print ( t2 - t1 , 's' ) object_size_in_words = 2 # GC header, one integer field mem = loops * 8 * object_size_in_words / 1024.0 / 1024.0 / 1024.0 print ( mem , 'GB' ) print ( mem / ( t2 - t1 ), 'GB/s' )
Then we need to add some RPython scaffolding:
... continue reading