No, V8's regex library is not written in C. V8 compiles its regular expressions to machine code at runtime. The availability of the compiler at runtime can be a liability for things like startup time or memory use, but can also be a key advantage in situations like regular expression parsing or packet processing.
You need a regex library to turn a regex into machine code. What the parent means is that the V8 regex library compiles them, while the one used in the C code merely interprets the regex.
(The C and C++ thing is just adding confusion here)
Regular expressions are part of the JavaScript language, so they're as much "written in JavaScript" as any other language construct.
The point is that a regular expression compiled by V8 (which is not written in JavaScript) is faster than a regular expression as compiled by some particular C compiler. Of course a C compiler could possibly be written to understand calls to a standard regexp API and compile those to binary.
But it does show how good V8 is at optimizing out the JS part of JS when it's irrelevant to the computation, and it shows how well-optimized the regexps in V8 are.
None of this is terribly surprising given V8's use case, but only a few years back this would have been a ridiculous result. I enjoyed taking a minute to reflect on that.
It's not JavaScript bytecode, but regex bytecode. V8 parses regular expressions to regex ASTs, takes them through some more intermediate forms, then finally to a special regex bytecode. That bytecode is either interpreted, or JIT compiled (depending of some build options, I think).
You can look at a list of bytecodes in [1], and at the x64 JIT in [2].
Reading through the responses to this comment, the upshot w.r.t regex performance is that it's a significant advantage to have native regex support in a language. Because C doesn't the regex ultimately has to be translated into C at parse time, whereas with Javascript the regex is converted to machinecode at run time.
This is similar to the advantage of abstraction layers in general, although there's a cost if you create abstraction layers for things no-one much cares about.
Rather than argue back and forth about which regex implementation is better here, I'd simply note the absence of multicore numbers for V8 and that the crappy Tcl library beats single-threaded Javascript when run multicore.
It would be interesting, however, to compare the performance here to that of the "grep" command on the same expressions. I'd be surprised at anything short of a total smackdown of Javascript V8.
I would expect an even bigger smackdown if one invoked GPUs:
The idea was obviously to pick a test and environment that would make it look like V8 can beat something other than interpreted JS. Otherwise it would've been the complete package: string manipulation, numerical computation, multi-core etc.
Likely because V8 only works on platforms where JIT is possible, so the regex engine relies on JITting specialized native code for the regex. A portable C/C++ regex library can't really do that.
The V8 version used nearly 50% more memory than the C version. It is well known that you can often get faster execution times at the cost of increased memory usage.
Go not only uses a different library for processing regular expressions, but a different algorithm altogether. It is slower in some cases than the standard PCRE implementations but faster in others.
