Isn’t one of the downsides of this approach that you can’t tell how large an allocation is until you dereference it? With traditional separate tracking of length (or even with “german strings”), you can tell how long a string is without having to look at it. With something like memcpy, none of the control flow depends on src or dst. If you have a cache miss, the processor can keep executing past the call, since it already knows how much data to copy. With cello, if you have a cache miss the processor has to wait in order to find out how much to copy.
Yes, and this is IIRC the reason why C++’s string and vector classes carry the size inline, not in the allocated heap block. It makes the object bigger, but having to dereference to get the size was bad for performance.
Isn’t one of the downsides of this approach that you can’t tell how large an allocation is until you dereference it? With traditional separate tracking of length (or even with “german strings”), you can tell how long a string is without having to look at it. With something like
memcpy, none of the control flow depends onsrcordst. If you have a cache miss, the processor can keep executing past the call, since it already knows how much data to copy. With cello, if you have a cache miss the processor has to wait in order to find out how much to copy.Indeed, and this design also does not gracefully handle slicing
Yes, and this is IIRC the reason why C++’s string and vector classes carry the size inline, not in the allocated heap block. It makes the object bigger, but having to dereference to get the size was bad for performance.