> But that’s not the fastest approach: the fastest approach is to just hold a pointer.
If you’re only storing the string and not doing anything else with it, then perhaps. But if you frequently access the string as the same time as the rest of your existing data structure, than an additional pointer dereference might reduce cache efficiency and increase latency.
So, if you’re preoccupied with the cost of that string, you should probably measure your actual use case.
Referencing the string by raw pointer is efficient on the initial copy but realistically only has downsides after that e.g.
* Lifetime guarantees/invariants of the original string
* Null pointer checks in all accessor/calling code
* Memory locality and cache behaviour (as already pointed out)
…so a judgment call would need to be made on the use expectations as Antoine mentioned.
One powerful trick that std::string relies upon are short-string optimization, whereas short strings are stored directly in the string object itself, therefore avoiding any kind of heap allocation.
> But that’s not the fastest approach: the fastest approach is to just hold a pointer.
If you’re only storing the string and not doing anything else with it, then perhaps. But if you frequently access the string as the same time as the rest of your existing data structure, than an additional pointer dereference might reduce cache efficiency and increase latency.
So, if you’re preoccupied with the cost of that string, you should probably measure your actual use case.
Interesting point.
Referencing the string by raw pointer is efficient on the initial copy but realistically only has downsides after that e.g.
* Lifetime guarantees/invariants of the original string
* Null pointer checks in all accessor/calling code
* Memory locality and cache behaviour (as already pointed out)
…so a judgment call would need to be made on the use expectations as Antoine mentioned.
First, almost a nit. The “outdata” is reused once, so perhaps not the same. I did see a change when block-scoping “outdata”.
$ ./build/b0
short strings:
5.09394 **1.63144** 0.405696 0.60292
long strings:
13.0458 **2.9494** 0.384981 1.36331
Run with “outdata” virgin for both tests.
$ ./build/b0
short strings:
5.21159 **1.46637** 0.344897 0.573364
long strings:
13.6949 **1.62891** 0.351345 0.788565
Had some free time, so played around with benchmarking C-with-classes style strings.
C-with-classes string benchmark on Github
Seems that std::string improved dramatically at some point?
Your link is not working (private content?).
One powerful trick that std::string relies upon are short-string optimization, whereas short strings are stored directly in the string object itself, therefore avoiding any kind of heap allocation.
Yep, was private, and is now public.