3 ms·

How does this make a difference? The articel states that it becomes slower when two strings don't fit together in one cache line anymore. That is independend o

• Sharlin 8y ago
  A stack variable is almost always already in the cache.
• jonhohle 8y ago
  I’m assuming the OP meant that there is a higher likelihood of SSO strings (24 bytes)§ being in the same cache line (64 bytes)§ when they are stored in the same stack frame. Two small strings allocated on the heap at different times have a lower likelihood of being in the same cache line. Even within consecutive mallocs the addresses might not fall within the same line. Unless the memory is allocated exlipicitly for locality, there’s a higher likelihood (>=0) that memory fragmentation causes the allocations to be split on different lines. Ultimately, this can be controlled on either the heap or stack, SSO seems to be optimizing for the stack case, which probably works pretty well for most cases (especially for oblivious developers). § on recent x86-64 processors
  • sigi45 8y ago
    But I don't create a string on the stack first. First allocation on the heap than probably a copy onto the stack.
• CyberDildonics 8y ago
  Two string on the stack are far more likely to be cached at a low cache level and/or prefetched (but probably already cached). A noticeable difference is much more likely to be because a string is too big and moved to the heap, which is in a different part of memory and thus not cached. Also there is the translation look aside buffer which caches the virtual memory to real memory address lookup. This also needs to be done on cold pages of memory and be expensive since it requires looking up in to the virtual memory table.