4 ms·

It's true that performance is not always the main metric to consider but in this case I'm not really sure that Go makes that much of a difference. Take the "reg

• weavie 8y ago
  Go seems to perform really poorly in the regex-redux. Against both Node and Python Go is way faster (as one would expect) apart from with the regex-redux.. https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-node.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-python3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Does Go just suck with it's regex performance? Would this be easy to fix by just pulling in a C regex library?
  • tex0 8y ago
    The benchmark is using some third party PCRE lib. This is probably necessary because Go's RE2 lacks some features, but it's not a good comparison.
    • burntsushi 8y ago
      > This is probably necessary because Go's RE2 lacks some features No, it's because PCRE is faster than Go's standard library regex engine on this particular benchmark. There is another entry for Go (called just `Go` I believe) that uses Go's "regexp" package. The regexredux benchmark itself does not require any "fancy" features. It can be satisfied by pure regular expressions.
    • deleted 8y ago
      [deleted]
  • jerf 8y ago
    I disagree with the people saying the benchmarks game is useless. It mostly seems to conform to my own experiences with the various languages involved. The exception is the regex benchmark, which has little to do with the languages and everything to do with the regex library used by the language. If the dynamic scripting languages were required to use regex engines implemented in pure Python/Perl/PHP/JS, their performance in the game would collapse on the regex benchmark. Go's standard library provides a regex library that provides certain O() guarantees, but has a significantly larger constant factor than PCRE-like regexs. Benchmarks tend to hit cases where PRCE is faster, but it's not hard to construct a benchmark where the Go standard library will be arbitrarily faster than some of the other languages, because that's a characteristic of big-O differences. (In general, one should always be careful of claims that some block of code is X times faster or slower than another; the comparison only has meaning if they're in the same big-O class, or at least de facto in the same big-O class, e.g., O(n logn) and O(n logn logn) are basically the same class in practice. It's also important to make sure the problem being benchmarked is large enough to get past the constant factors that may be involved. I'm not saying those aren't important, but if you want an "X-times faster" sort of comparison you need to shrink the constant factors into irrelevance first. I've seen cases where people blithely claim some bit of code is 100,000 faster than some other, but really, it's a big-O difference.)
    • weberc2 8y ago
      > I disagree with the people saying the benchmarks game is useless. It mostly seems to conform to my own experiences with the various languages involved. I think it can only tell you about the performance cieling, and even then it can't tell you that for languages like Go where fairly obvious optimizations (like arenas) are prohibited while all manner of clever tricks are permitted for other languages. Your remarks on performance comparisons were really insightful.
      • igouy 8y ago
        >> obvious optimizations (like arenas) are prohibited No, not prohibited. Which widely-used third-party Go library do you suggest people use to implement Go binary-trees programs?
• chatmasta 8y ago
  What stuck out to me about the regex-redux benchmark is that PHP is faster than both of them! Is that because PHP is effectively a scripting language over C, especially for well-defined tasks like regex matching?
  • burntsushi 8y ago
    I don't know personally. In Oct 2017, the PHP version was slower: http://web.archive.org/web/20171027211857/http://benchmarksgame.alioth.debian.org/u64q/regexredux.html http://web.archive.org/web/20171027211857/http://benchmarksg... Today, it is faster: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/regexredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... As far as I can tell, the source code of the benchmark didn't change at all. The only difference between them is that former uses PHP 7.1 and the latter uses PHP 7.2. So... I would start at the differences between PHP 7.1 and PHP 7.2. I would also first attempt to reproduce the result locally, to rule out changes in environment in the benchmark game (speculatively speaking).
• weavie 8y ago
  You aren't really going to experience Rusts complexity when your program is essentially just a single function, so it probably isn't really a fair comparison..
  • v_lisivka 8y ago
    When programs grows in complexity, Rust shines. Extra guarantees are very handy when code refactored. It hard to compile Rust code, but when it compiled, it usually works (or quickly points out to problem). I actually use it in parallel with C/C++ legacy code, and I just trying to avoid C/C++ as much as I can, because I newer saw segfault in safe Rust code so far.
  • smcl 8y ago
    Especially when you're just reading some pre-written code. I've rarely (never?) seen any complaints about how reading Rust is hard ... but lots which say that writing the code itself can be frustrating