Rapidstring: Maybe the fastest string library ever
1–10 of 62 posts
Re: Rapidstring: Maybe the fastest string library ever
#2>rapidstring is maybe the fastest string library ever written in ANSI C
Re: Rapidstring: Maybe the fastest string library ever
#3I 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.
Re: Rapidstring: Maybe the fastest string library ever
#4The author's last name gives some credibility that they might be good with strings.
Re: Rapidstring: Maybe the fastest string library ever
#5The author's last name gives some credibility that they might be good with strings.
The Boyer–Moore string-search algorithm?
Re: Rapidstring: Maybe the fastest string library ever
#6I 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 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.
Re: Rapidstring: Maybe the fastest string library ever
#7I 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"
Re: Rapidstring: Maybe the fastest string library ever
#8I’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 all sorts of abi issues - basically, if your own app uses this it can’t expose it to plugins or anything, otherwise any update could break existing compiled plugins.
Re: Rapidstring: Maybe the fastest string library ever
#9I 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 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.
Re: Rapidstring: Maybe the fastest string library ever
#10The author's last name gives some credibility that they might be good with strings.
True, but sadly no relation in this case, it appears.