Mux regular expression - "regexp" vs "pcre"

[Java Pro]

Mux package is using Go's built in "regexp". Have we considered using "PCRE"? 

For matching strings shorter than 29 characters, "pcre" is usually faster than Go's "regexp". 

I saw the benchmark below using "pcre" from Go and the speed is 3 times as fast as Go's "regexp".

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=regexdna&lang=all&data=u64q

Note: Go #8 in the benchmark is using github.com/glenn-brown/golang-pkg-pcre/src/pkg/pcre

Since Mux is usually matching IDs and short names in a URL, I would assume they are usually less than 29 characters. To improve performance, have we considered using "pcre" for Mux?

Best regards,

JPro

[Kamil Kisiel]

Do you have some benchmarks that show the regexp speed is a limiting factor in dispatching requests?

[Java Pro]

I don't have my benchmarks to indicate it is a limiting factor. 

Ruby is 4 times and PHP is 1 time faster in the benchmark shootout. People switching from Ruby or PHP pay attention to how URL looks and would be surprised to see Go is a few times slower to process what they used to do before switching over. 

I understand that Ruby and PHP implement Regex using C as they are scripting languages. Also, Go chooses DFA over NFA underneath. 

Just wish Go can do better in short string matches. Can Go optimize "regexp" in C/ML and beat them all? 

Or, Can go accept a flag to allow NFA / DFA selection when implementing "regexp", not binding to DFA in the current implementation? 

JPro

[Kamil Kisiel]

Realistically I doubt the regexp parsing of the routes is going to make much of a difference in most applications. If it can be shown to do so then we could look at trying to optimize it, but otherwise I don't think it's worth introducing an external dependency because of the results of a synthetic benchmark.

[Java Pro]

Agreed. If running into performance issues, then we can revisit how to optimize. Thanks.