[JoachimSchipper]

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.

[pcwalton]

> 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]

Nitpick: 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]

Yes, definitely true; sizeof(void *) and malloc slop aren't free.

[jheriko]

sizeof( void* ) is free at run-time.

if not then the compiler team should rethink their careers...

[ctz]

I think the parent is saying that pointers need storage too and this can add up, not that sizeof expressions are computationally difficult :)

[eternalban]

Got 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]

(and also reducing the number of malloc/free calls)