6 ms·

Looks like it uses regexp... There isn't any benchmark code as one would expect when making a claim that it's "fast".

laumars 10y ago
Regexp definitely isn't something you'd want to be using if you're primary goal is speed. When running tight loops in string parsing I've found using string splitting and then cycling through the range of indices in a slice was several times faster than Regexp matching. Obviously performance difference will vary depending on the expression and application but that was enough to convince me to think twice about future usage of Regex - as to whether the problem needed Regex or if I was just using them lazily. The latter being a practice I'd slipped into after years of Perl hacking.
- jules 10y ago
  That depends entirely on the regex implementation. If the implementation uses a DFA to match multiple regexes simultaneously then the performance will be as good as a trie because a DFA is more or less a trie.
  - vanderZwan 10y ago
    > That depends entirely on the regex implementation True, and anyone who knows that Russ Cox is a core member of the Go team will have a hard time suppressing a smirk when reading this :) https://swtch.com/~rsc/regexp/ https://swtch.com/~rsc/regexp/
  - laumars 10y ago
    True. I was talking specifically about the same Regexp package as the one used in the topic project though. I assumed that would have been obvious given the context however I apologise for not stating that in my comment and shall amend it appropriately. [edit: i can't add an amendment to my previous post now]
  - mypalmike 10y ago
    True. But nowadays most regex implementations are quite good (apparently go's is not - I haven't used it). That said, most regex performance problems are PEBKAC. Writing a fast regex is hard and requires a pretty thorough understanding of parser theory. And many who use regexes don't understand that it's critical to precompile them for performance. You don't get a fast parser when you rebuild the DFA each time you use it. *edit: a word
aikah 10y ago
Go regexps are slow (https://goo.gl/r0K2xw https://goo.gl/r0K2xw ), the problem is not regexps but Go's implementation of regexps. So let's not blame regexps when regexps aren't the problem. Because by that logic, people shouldn't use the sort package as well ...
- creshal 10y ago
  Regexes are the problem, because they're simply the wrong tool for the job.
  - aikah 10y ago
    > Regexes are the problem, because they're simply the wrong tool for the job. for what job? Extracting route variables from paths ?they are the right tool for the job, only in the Go community they are deemed "wrong tool for the job". Your statement embodies everything that is wrong with the Go community. Instead of finding a solution to a problem you guys spend your time shifting the blame on "bad practices".
    - deleted 10y ago
      [deleted]
    - rudolf0 10y ago
      Wouldn't it make more sense to use something faster and simpler for most routing, and then an optional argument for regular expressions? Lots of web frameworks use that approach.
- laumars 10y ago
  You're making a distinction where one doesn't need to be made. It doesn't matter if regexp is generally slow or if it's Go implementation specifically - if you're using Go and wanting something where performance is your primary goal then you're generally best to avoid using regexp.
  - aikah 10y ago

Regexp definitely isn't something you'd want to be using if you're primary goal is speed. When running tight loops in string parsing I've found using string splitting and then cycling through the range of indices in a slice was several times faster than Regexp matching. Obviously performance difference will vary depending on the expression and application but that was enough to convince me to think twice about future usage of Regex - as to whether the problem needed Regex or if I was just using them lazily. The latter being a practice I'd slipped into after years of Perl hacking.

jules 10y ago
That depends entirely on the regex implementation. If the implementation uses a DFA to match multiple regexes simultaneously then the performance will be as good as a trie because a DFA is more or less a trie.
- vanderZwan 10y ago
  > That depends entirely on the regex implementation True, and anyone who knows that Russ Cox is a core member of the Go team will have a hard time suppressing a smirk when reading this :) https://swtch.com/~rsc/regexp/ https://swtch.com/~rsc/regexp/
- laumars 10y ago
  True. I was talking specifically about the same Regexp package as the one used in the topic project though. I assumed that would have been obvious given the context however I apologise for not stating that in my comment and shall amend it appropriately. [edit: i can't add an amendment to my previous post now]
- mypalmike 10y ago
  True. But nowadays most regex implementations are quite good (apparently go's is not - I haven't used it). That said, most regex performance problems are PEBKAC. Writing a fast regex is hard and requires a pretty thorough understanding of parser theory. And many who use regexes don't understand that it's critical to precompile them for performance. You don't get a fast parser when you rebuild the DFA each time you use it. *edit: a word

aikah 10y ago

Go regexps are slow (https://goo.gl/r0K2xw https://goo.gl/r0K2xw ), the problem is not regexps but Go's implementation of regexps. So let's not blame regexps when regexps aren't the problem. Because by that logic, people shouldn't use the sort package as well ...

creshal 10y ago
Regexes are the problem, because they're simply the wrong tool for the job.
- aikah 10y ago
  > Regexes are the problem, because they're simply the wrong tool for the job. for what job? Extracting route variables from paths ?they are the right tool for the job, only in the Go community they are deemed "wrong tool for the job". Your statement embodies everything that is wrong with the Go community. Instead of finding a solution to a problem you guys spend your time shifting the blame on "bad practices".
  - deleted 10y ago
    [deleted]
  - rudolf0 10y ago
    Wouldn't it make more sense to use something faster and simpler for most routing, and then an optional argument for regular expressions? Lots of web frameworks use that approach.
laumars 10y ago
You're making a distinction where one doesn't need to be made. It doesn't matter if regexp is generally slow or if it's Go implementation specifically - if you're using Go and wanting something where performance is your primary goal then you're generally best to avoid using regexp.
- aikah 10y ago