5 ms·

It shouldn't be like that, that's the problem. Regular expressions should be compiled into a native code and be even faster than a bunch of hand written bytes.H

by zzzcpan 11y ago

It shouldn't be like that, that's the problem. Regular expressions should be compiled into a native code and be even faster than a bunch of hand written bytes.HasSuffix() combinations.

sgift 11y ago
You've made me curious: Is there a language out there which does this, i.e. compiles Regex down to native code which is then as fast/faster than hand-coded bytes.hasSuffix(..) calls?
- nitrogen 11y ago
  I found this with a bit of searching and clicking around on Stackoverflow: https://www.colm.net/open-source/ragel/ https://www.colm.net/open-source/ragel/ (via http://stackoverflow.com/a/15608037 http://stackoverflow.com/a/15608037). I didn't look long enough to know if there's an easy way to convert a regular expression to Ragel syntax.
giovannibajo1 11y ago
Your previous post said that they are a very useful DSL for Perl so that "people don't have to do like they do in Go". Both Perl and Go implement regexps, and neither or them compile them to native code. So I don't get your previous comment at all. The main difference is that, in Perl, if you ever had to write manual string parsing, it would be much much slower than using regexps as Perl is an interpreted language. So regexps are needed to perform fast string parsing. In Go, you have regexps if you want, or you can go even faster if you feel it's required.
- zzzcpan 11y ago
  > Both Perl and Go implement regexps, and neither or them compile them to native code. So I don't get your previous comment at all. Ok, I'll try to explain. People feel discouraged to use regexps in Go, because they are very slow for many typical parsing and validating cases and require extra step of compilation and all of the additional code complexity associated with that. So, people do parsing manually instead, with all of its problems. It's not that they need that performance, almost no one does, but the whole idea behind regular expressions is not working, parsing code is still bad most of the time.

by zzzcpan 11y ago

It shouldn't be like that, that's the problem. Regular expressions should be compiled into a native code and be even faster than a bunch of hand written bytes.HasSuffix() combinations.

sgift 11y ago

You've made me curious: Is there a language out there which does this, i.e. compiles Regex down to native code which is then as fast/faster than hand-coded bytes.hasSuffix(..) calls?

nitrogen 11y ago
I found this with a bit of searching and clicking around on Stackoverflow: https://www.colm.net/open-source/ragel/ https://www.colm.net/open-source/ragel/ (via http://stackoverflow.com/a/15608037 http://stackoverflow.com/a/15608037). I didn't look long enough to know if there's an easy way to convert a regular expression to Ragel syntax.

giovannibajo1 11y ago

Your previous post said that they are a very useful DSL for Perl so that "people don't have to do like they do in Go". Both Perl and Go implement regexps, and neither or them compile them to native code. So I don't get your previous comment at all. The main difference is that, in Perl, if you ever had to write manual string parsing, it would be much much slower than using regexps as Perl is an interpreted language. So regexps are needed to perform fast string parsing. In Go, you have regexps if you want, or you can go even faster if you feel it's required.

zzzcpan 11y ago
> Both Perl and Go implement regexps, and neither or them compile them to native code. So I don't get your previous comment at all. Ok, I'll try to explain. People feel discouraged to use regexps in Go, because they are very slow for many typical parsing and validating cases and require extra step of compilation and all of the additional code complexity associated with that. So, people do parsing manually instead, with all of its problems. It's not that they need that performance, almost no one does, but the whole idea behind regular expressions is not working, parsing code is still bad most of the time.