> Won't the pointer also be hot in cache in this case? Depends on the situation; the parent was somewhat vague. As one example, suppose you've previously crea

> Won't the pointer also be hot in cache in this case? Depends on the situation; the parent was somewhat vague. As one example, suppose you've previously created a `struct foo`, but you haven't accessed it in a long time; then fetching any of its fields will probably be a cache miss. But if it contains a pointer, fetching data from that pointer will probably be a second cache miss – which can't even be started until the first one completes, because the CPU doesn't know what the pointer is. If `struct foo` contains the data directly, there's a good chance it all fits in a single cache line (typically 64 bytes). But even if it's split across, say, two cache lines, the CPU knows which cache lines need to be accessed, so it can send off the second request without waiting for the first one to complete. That said: - Strings are variable length, so they usually can't be stored in place anyway, although some languages/frameworks have "small string optimization", meaning that sufficiently short strings are stored in the space that would otherwise be used for the pointer and length. - In general, Swift is hardly a good role model when it comes to performance. :p