4 ms·
Chiefly, just using fewer pointers. That is, turn struct foo { struct bar *bar; struct baz *baz; } into struct foo { stru
by JoachimSchipper 11y ago
Chiefly, just using fewer pointers. That is, turn
struct foo {
struct bar *bar;
struct baz *baz;
}
into
struct foo {
struct bar bar;
struct baz baz;
}
Of course, this is not always possible - but a C program written naively/for encapsulation/flexibly tends to have a lot of places where you can perform such an optimization.
The performance win, on modern platforms, comes chiefly from reducing the number of (unpredictable/non-cached) pointer dereferences.
- eternalban 11y agoGot it, thank you. I've been experimenting with a less general segmented & offset addressed approach to deal with the same issues. Quite surprising how much semantics can be encoded in 64 bytes. Performance gains are substantial.
- paraboul 11y ago(and also reducing the number of malloc/free calls)
- pcwalton 11y ago> The performance win, on modern platforms, comes chiefly from reducing the number of (unpredictable/non-cached) pointer dereferences. The parenthetical is important. Pointers are just fine as long as you don't dereference them and suffer cache misses as a result. It's also worthwhile to note that what you described is not always a worthwhile optimization, even if you can do it. If, for example, you traverse an array of the objects containing a sub-object frequently and follow the pointer to that object only rarely, it's often worthwhile to allocate it separately to improve cache locality of that traversal. This is even more important if you're doing a lot of structure copies of the outer structure; avoiding copying more bits saves a lot of time. The latter case comes up surprisingly often in my experience, and I've improved performance of code quite a few times with separate allocations and pointer indirection.
- tptacek 11y agoNitpick: they're fine in otherwise-reasonable code as long as they aren't shredding the cache. But there are lots of unreasonable designs that waste tons of space, further burning up locality even when the pointers aren't traversed, that are due to pointer overuse.
- pcwalton 11y agoYes, definitely true; sizeof(void *) and malloc slop aren't free.