News for hackers. Stuff that matters.

A comment on Experience porting 4k lines of C code to go. Parent comment

Re:Experience porting 4k lines of C code to go by knome on Tuesday June 21, 2011 @05:31PM (#2680513)
> because regexpes are heavily optimized C code

AFAIK, the python re module does not have a C language component. It is a pure python regular expression implementation.

[ Parent | on HN ]
Re:Experience porting 4k lines of C code to go by kkowalczyk on Tuesday June 21, 2011 @05:55PM (#2680601)
That's not true: http://hg.python.org/cpython/file/d1d5a7392e39/Modules/_sre....
[ Parent | on HN ]
Re:Experience porting 4k lines of C code to go by enneff on Tuesday June 21, 2011 @06:50PM (#2680745)
Most dynamic languages use a C Regular Expression library. That's why they can do so well on Regular Expression benchmarks.

V8 is a notable exception. They use their code generation pipeline to JIT compile regexps to machine code, making it the fastest regexp engine around bar none (I think).

[ Parent | on HN ]
Re:Experience porting 4k lines of C code to go by azakai on Tuesday June 21, 2011 @07:51PM (#2680911)
AFAIK all modern JS engines JIT regexps: V8, SpiderMonkey and Nitro.
[ Parent | on HN ]
Re:Experience porting 4k lines of C code to go by pavpanchekha on Wednesday June 22, 2011 @03:59AM (#2682195)
I'd like to put in a word for CL-PPCRE, the Common Lisp regex library. It does the same except using the CL optimizing compiler, so also achieves amazing speed.

Libraries don't appear in the Comp.Lang.Benchmark Shootout, so CL doesn't do so well.

[ Parent | on HN ]
Re:Experience porting 4k lines of C code to go by silentbicycle on Tuesday June 21, 2011 @11:37PM (#2681597)
What about LPEG? It has a superset of the functionality of most regexp engines, yet is able to handle many things linearly that they would handle in quadratic time.
[ Parent | on HN ]
Re:Experience porting 4k lines of C code to go by silentbicycle on Tuesday June 21, 2011 @11:34PM (#2681585)
Performance-wise, any regex-based implementation may spend a lot of time backtracking and re-parsing data that a DFA hand-coded parser would handle in linear time.
[ Parent | on HN ]