3 ms·

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.. htt

• 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?
      • weberc2 8y ago
        > No, not prohibited. Yes, prohibited > Which widely-used third-party Go library do you suggest people use to implement Go binary-trees programs? What does this have to do with my post?
        • igouy 8y ago
          >> What does this have to do with my post? You falsely claim that Go arenas are prohibited. Show that there is a widely-used third-party Go library that provides arenas, which could be used to implement Go binary-trees programs, to support your claim.
  • _ek94 8y ago
    > Go's standard library provides a regex library that provides certain O() guarantees, but has a significantly larger constant factor than PCRE-like regexs. While that is true, Rust's regex library makes the same guarantees. I'd also like to push back on the idea that perf comparisons are meaningless if one implementation has degenerate cases. Pathological behavior in a backtracking engine happens very rarely, and backtrackers typically come with features that are not supplied by O(n) engines. Someone in the PCRE camp might complain that the benchmark isn't fair because go's engine can't handle backreferences. The different approaches come with different features (backreferences vs garenteed O(n) running time), but they do have a place where their problem domains overlap. It is not useless to examine how they perform in that area.