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

[Vadim Zeitlin]

On Sun, 14 Oct 2018 21:53:37 +0000 Greg Chicares <address@hidden> wrote:

GC> I'd be reluctant to introduce a dependency on another third-party
GC> library. Obviously the author must be a really good programmer to
GC> make this work at all, but there are probably unknown defects, and
GC> we can't be sure that they'll be fixed, or that this library will
GC> be maintained over the years.

 This is true. However, assuming that it works right now (which is, again,
an assumption not based on any testing), I wonder if we care. After all,
the definition of regexes is not going to change and we don't really
require any new features from this library.

GC> Ideally, either this would be added to the C++ standard,

 This might well happen (I'd definitely consider doing it if I were a C++
standard committee member), but not in C++20.

GC> or the libstdc++ maintainers would figure out how to make their
GC> implementation much faster (either by adapting this research, or at
GC> least by doing whatever boost does); but neither of those seems very
GC> likely.

 I'm still extremely puzzled by the huge speed discrepancy between
boost::regex and std::regex (MSVS implementation is not too bad, but both
libstdc++ and libc++ are slower by orders of magnitude, so it's not just
libstdc++). I think boost library must be cutting some cortners to achieve
its speed and that the std implementation can't afford to do it. Again, I
have absolutely no proof of this, but it's just that I see no other
explanation for this.

GC> If that idea doesn't make the problem so small that we no longer
GC> object to the run time, then--at a future time when we can remove
GC> boost completely--we'll want to consider doing something else.
GC> I think rewriting test_coding_rules as a perl script might be
GC> preferable to trading one old C++ library for a newer C++ library,
GC> because we can be sure perl will be maintained actively for many
GC> years to come.
GC> 
GC> (I'd like it even better if we could translate it to a vim macro,
GC> because then I wouldn't have to study perl; but that's probably
GC> not very practical.)

 I love Vim, but I don't enjoy programming in VimScript and would much
prefer doing this in Perl, even though it definitely could be done in
VimScript too (but then you'd need Vim to run the concinnity check, which
doesn't seem right, does it?).

 Something that I would like to do in Vim is to add highlighting rules that
would immediately show at least some of the deviations from the coding
style that this check finds. But this probably won't be very useful to you
and arguably not worth doing just for my own convenience.

 Regards,
VZ