Is performance really the first thing we should worry about when it comes to string libraries for C? Given the dismal history of character arrays in C, I'd expect safety to be the first thing on the mind of any library implementer, and the first thing mentioned in the README. Also, the second, third, and fourth things.
Rapidstring: Maybe the fastest string library ever
11–20 of 62 posts
Re: Rapidstring: Maybe the fastest string library ever
#12I’d be more interested in “this is faster than X” claims if it does a fair comparison - pushing the implementation out of the header. Otherwise (depending on operation) inlining ends up significantly throwing off performance numbers. That said it’s much easier to make faster than libN string libraries if you don’t have abi constraints to deal with. This uses any value struct to hold much of its metadata which causes…
> The current benchmarks outperform the standard string implementations of GCC, Clang, MSVC and ICC by a factor of two or more in most tests.
Re: Rapidstring: Maybe the fastest string library ever
#13Is performance really the first thing we should worry about when it comes to string libraries for C? Given the dismal history of character arrays in C, I'd expect safety to be the first thing on the mind of any library implementer, and the first thing mentioned in the README. Also, the second, third, and fourth things.
In what sense would safety be such a high priority for a high performance string library? I found this blog post was good at illustrating why undefined...similar to unsafe...operations exist https://nullprogram.com/blog/2018/07/20/
Re: Rapidstring: Maybe the fastest string library ever
#14Earlier quoted context omitted.
I don't really know why you are being downvoted. There are a lot of string libraries that do not work well with Unicode strings. If you natively speak any non-European language it can be hard to use those libraries to effectively solve your problems. Not to bad mouth this project, but we don't really need a fast incomplete library.
In the modern development environment, I think it's genuinely fair to say that something which doesn't support Unicode strings cannot be claimed to support strings. It's like saying you have the fastest integer math library ever written, with the minor caveat that it only supports numbers smaller than 256 because it achieves that speed by being simply a hardcoded lookup table, and crashes if you give it anything else…
Does this library crash like in your example though? There's a difference between "not having Unicode-specific features" and "failing when given Unicode input".
Re: Rapidstring: Maybe the fastest string library ever
#15Hey there, creator of the library here. Strangely enough my initial post about this on HN received no attention, but better late than never!
If any of you have some questions or feedback, I would be delighted to hear it.
Re: Rapidstring: Maybe the fastest string library ever
#16I like the stack trick. But it's still just a membuf library, without any string support. No encoding, no Unicode, no upper/lower/fc/norm support, which would be important to compare or find strings. And coreutils (e.g grep) still have no unicode support. It's 2018, not the seventies anymore. Unicode strings need to be normalized to be able to be found.
I think instead is better to title this as "maybe the fastest ascii string library"
Unicode is supported with UTF-8, only different character types aren't supported because generics are messy in C. I thought of accepting void* to support wchar_t and others, but some performance penalties came with it so I decided against it.
Re: Rapidstring: Maybe the fastest string library ever
#17Re: Rapidstring: Maybe the fastest string library ever
#18Is performance really the first thing we should worry about when it comes to string libraries for C? Given the dismal history of character arrays in C, I'd expect safety to be the first thing on the mind of any library implementer, and the first thing mentioned in the README. Also, the second, third, and fourth things.
And though it’s peculiar that the readme doesn’t mention it, the code is (trying to be) safe, at least when assertions aren’t disabled.
Re: Rapidstring: Maybe the fastest string library ever
#19I’d be more interested in “this is faster than X” claims if it does a fair comparison - pushing the implementation out of the header. Otherwise (depending on operation) inlining ends up significantly throwing off performance numbers. That said it’s much easier to make faster than libN string libraries if you don’t have abi constraints to deal with. This uses any value struct to hold much of its metadata which causes…
Most of the STL is header only, which is what the library is compared to in the benchmarks. Both would be just as likely to get inlined.
Re: Rapidstring: Maybe the fastest string library ever
#20Hey there, creator of the library here. Strangely enough my initial post about this on HN received no attention, but better late than never! If any of you have some questions or feedback, I would be delighted to hear it.
Hey man don't worry about that, that's just the way of life. People notice things when they do, that part's not up to us. I've seen articles here posted years after they were written.
Very nice and thoroughly documented code! Well done! What gave you the initial idea to write this maybe-fastest-ever string library? Did you just have an idea one day of how it could be done and you just went for it? Or did you have a performance issue and come up with this to speed something up at work, or what?