News for hackers. Stuff that matters.
Re:Rapidstring: Maybe the fastest string library ever by olliej on Tuesday July 31, 2018 @08:29PM (#17658590)
I’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 by johnboyer on Tuesday July 31, 2018 @10:14PM (#17659121)
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 by flohofwoe on Wednesday August 01, 2018 @03:29AM (#17660334)
Whether a function body is implemented in a header or implementation source file doesn't matter much these days where LTO/LTCG is common. If the compiler/linker thinks a function is fit for inlining it will do so.
Re:Rapidstring: Maybe the fastest string library ever by ddtaylor on Tuesday July 31, 2018 @09:41PM (#17658962)
> The current benchmarks outperform the standard string implementations of GCC, Clang, MSVC and ICC by a factor of two or more in most tests.