Would compiling a regex into native assembly be faster than PCRE or other Regex engines?
assembly, c++, pcre, perl, regex
Solution
I think the answer to this one is pretty obvious. Ideally, yes, it could be. But even if you're very clever at this kind of thing it would take a very large development effort to get to a point where, for the most part, you're only slightly better than available libraries — and even longer to work all of the bugs out. So there's not much point in it.
Problem
I was thinking about an improvement. I'm currently doing lots of text processing of log files. I don't mean to say PCRE is slow/fast or any other implementation for that matter. The language I'm writing in is primarily Perl. I know it has a powerful regex engine and I know it's more expressive than PCRE. I have this idea about making a small regex engine in C++ that would compile a regex to raw nasm. I'm aware PCRE is quite complex and my assumption is that I could skip a lot of things done by PCRE in terms of non-necessary processing. And I could certainly make this faster than Perl since it operates with vm-like opcodes and all sorts of things that could be considered as being overhead. I already started an implementation some time ago. I'm not going to post it here since I don't have any problems with it, I could carry it out to the end and obtain a regex engine capable of doing captures, capable of interpreting `+` `*` `^` `$` , character classes (although I haven't done the part where I'll convert the regex to assembly language) Would this be a good idea or a bad idea? What could go wrong in terms of reaching a good performance with this? tl;dr => could a C++ mini-regex engine that would produce native assembly be faster than established regex implementations?