Re: [lmi] Solution to std::regex slowness

[Greg Chicares]

On 14/10/2018 20.08, Vadim Zeitlin wrote:
> 
>  This is not necessarily the most urgent thing to do, but if you remember,
> we had to keep using boost::regex instead of switching to std::regex
> because the latter was almost unusably slow, unlike the former.

Yes. IIRC, you even tried parallelizing it with threads, but found
that that didn't help very much.

>  However I've just learnt about a header-only library which implements
> support for compile-time regular expressions:
> 
>       https://github.com/hanickadot/compile-time-regular-expressions
> 
> It's much faster than std::regex during run-time (no surprise here) but,
> amazingly, even seems to be faster than it at compile-time, at least if I
> trust the benchmarks from
> 
>       
> https://github.com/CppCon/CppCon2018/raw/master/Presentations/compile_time_regular_expressions/compile_time_regular_expressions__hana_dusikova__cppcon_2018.pdf

That's an interesting presentation indeed.

>  The main drawback is that this library requires a C++20 compiler (which
> don't exist yet) or a C++17 compiler with not (yet?) accepted extension,
> which means, in practice, either g++ 7.2+ or clang 5.0+ -- but no MSVS.
> However considering that boost::regex is only used in test_coding_rules, I
> could live without being able to compile this tool with MSVS if it means
> getting rid of boost::regex and also, potentially, speeding it up.
> 
>  Of course, I haven't actually tested whether this is going to work, i.e.
> we might use some of Perl RE features not supported by this ctre library.
> But if you think it could be interesting, I definitely could at least try
> to do this, after the other, more urgent, items are dealt with.

I'd be reluctant to introduce a dependency on another third-party
library. Obviously the author must be a really good programmer to
make this work at all, but there are probably unknown defects, and
we can't be sure that they'll be fixed, or that this library will
be maintained over the years. Ideally, either this would be added
to the C++ standard, or the libstdc++ maintainers would figure out
how to make their implementation much faster (either by adapting
this research, or at least by doing whatever boost does); but
neither of those seems very likely.

Right now, 'make check_concinnity' does more work than it needs to,
because it runs xml_lint and test_coding_rules without saving their
results. OTOH, 'make check_physical_closure' saves the outcome for
each file, and updates it only when the file changes; if the
concinnity check did that, then maybe we wouldn't mind using a
test_coding_rules binary built with std::regex.

If that idea doesn't make the problem so small that we no longer
object to the run time, then--at a future time when we can remove
boost completely--we'll want to consider doing something else.
I think rewriting test_coding_rules as a perl script might be
preferable to trading one old C++ library for a newer C++ library,
because we can be sure perl will be maintained actively for many
years to come.

(I'd like it even better if we could translate it to a vim macro,
because then I wouldn't have to study perl; but that's probably
not very practical.)