Feature #10256
closed[PATCH] reduce rb_call_info_t 96 => 88 bytes on 64-bit
Description
Instead of using an 8-byte function pointer, use a small index
(may be <=1 byte, but currently 2 bytes for alignment) as array offset
and pack it next to flags (where only 9 bits are used).
Unfortunately, we cannot rely on C99, yet, so maintenance might be
a little uglier (but I think our test suite is good enough to cover).
Every word saved on rb_call_info_t seems to result in over 50K in startup
savings ("valgrind ruby -e exit").
before:
total heap usage: 49,111 allocs, 19,776 frees, 8,444,054 bytes allocated
after:
total heap usage: 49,057 allocs, 19,721 frees, 8,390,916 bytes allocated
Performance does not seem bad on Xeon E3-1230 v3 (8MB cache),
(minor +/- across the board):
http://80x24.org/bmlog-20140918-035740.9493
Files
Updated by normalperson (Eric Wong) over 9 years ago
- File 0001-make-rb_method_definition_t-smaller-via-rb_method_cf.patch 0001-make-rb_method_definition_t-smaller-via-rb_method_cf.patch added
Similar patch for rb_method_definition_t, tested on a different system due to
power outages.
Not much change, but minor improvements probably due to better locality
(method definitions are the same size as method entries, now).
http://80x24.org/bmlog-20140919-090128.6921
rb_method_definition_t is now 32 bytes (from 64) on a 64-bit system and
may be cache-aligned in the future to occupy half a 64-byte cache line.
Saves around 20K of allocations at startup with "valgrind ruby -e exit"
before:
total heap usage: 49,445 allocs, 20,027 frees, 8,492,836 bytes allocated
after:
total heap usage: 49,445 allocs, 20,040 frees, 8,472,372 bytes allocated
Updated by ko1 (Koichi Sasada) over 9 years ago
-1 because of performance concern (indirect access).
I'm not sure how it is impact for not so smart CPUs.
(I wondered that recent CPU doesn't care such indirection, maybe they have smart cache, branch prediction and so on.)
Updated by normalperson (Eric Wong) about 6 years ago
- Status changed from Open to Rejected