[Containers] String performance and compatibility
Hi Ion, I see that your string implementation has a small buffer optimisation (SBO). Have you tried to benchmark this, and/or any of the other design decisions? I vaguely recall that libc++ may have done some measurements but I can't find anything now. Also, have you considered adding e.g. a ctor that takes a std::string, for interoperability? (I guess the same could be asked for the other types.) Phil.
El 05/08/2011 1:44, Phil Endecott escribió:
Hi Ion,
I see that your string implementation has a small buffer optimisation (SBO). Have you tried to benchmark this, and/or any of the other design decisions? I vaguely recall that libc++ may have done some measurements but I can't find anything now.
I havent' measured it thoroughly. It's based on the same ideas libc++ uses, and I have no other non-SBO implementation to compare. Maybe an easy task is to compare this string with other standard libraries that use SBO.
Also, have you considered adding e.g. a ctor that takes a std::string, for interoperability? (I guess the same could be asked for the other types.)
That might be a good addition if there is consensus for that. You can just use target.assign(src.begin(), src.end()) but I think the constructor could optimize some conversions, like ordered containers. Ion
On 08/05/2011 07:59 AM, Ion Gaztañaga wrote:
El 05/08/2011 1:44, Phil Endecott escribió:
Hi Ion,
I see that your string implementation has a small buffer optimisation (SBO). Have you tried to benchmark this, and/or any of the other design decisions? I vaguely recall that libc++ may have done some measurements but I can't find anything now.
I havent' measured it thoroughly. It's based on the same ideas libc++ uses, and I have no other non-SBO implementation to compare. Maybe an easy task is to compare this string with other standard libraries that use SBO.
Quick question about the SBO: why are you using two static_casts, with one to void* and another to the target type, rather than the more explicit reinterpret_cast? Both have the same effects, but the latter could allow the compiler to issue warnings in case of strict aliasing problems. Unfortunately you cannot put long_t directly in the union (since pointer does not have to be a POD, I take it?), so I'm not sure the code can be made standard-conforming in C++03.
Also, have you considered adding e.g. a ctor that takes a std::string, for interoperability? (I guess the same could be asked for the other types.)
That might be a good addition if there is consensus for that. You can just use target.assign(src.begin(), src.end()) but I think the constructor could optimize some conversions, like ordered containers.
Containers have a constructor that takes two iterators. It might be interesting to extend this by adding a constructor that takes a single range argument.
El 05/08/2011 11:04, Mathias Gaunard escribió:
Quick question about the SBO: why are you using two static_casts, with one to void* and another to the target type, rather than the more explicit reinterpret_cast?
Stylistic issue, no problem to change it to reinterpret_cast if that helps diagnostics.
Unfortunately you cannot put long_t directly in the union (since pointer does not have to be a POD, I take it?), so I'm not sure the code can be made standard-conforming in C++03.
Not in theory, but all C++03 compilers treat this correctly. Anyway, maybe we could find a workaround to avoid defining the copy contructor (which is a limitation of the Boost.Move library, I think).
Containers have a constructor that takes two iterators. It might be interesting to extend this by adding a constructor that takes a single range argument.
Yes, in ordered containers there are optimization opportunities in case the range is guaranteed to be already ordered (and/or unique) with the same comparison functor. Best, Ion
participants (4)
-
Ion Gaztañaga -
Mathias Gaunard -
Nathan Ridge -
Phil Endecott