Performance Showdown: Rust vs Javascript (2020)

Re:Performance Showdown: Rust vs Javascript (2020) by IshKebab on Friday February 12, 2021 @07:07AM (#26112783)

Minor nit, but if you find yourself writing `return true` `return false`, it's a sign your code can be simplified. In this case:

  fn react(token1: &String, token2: &String) -> bool {
    token1.to_lowercase() == token2.to_lowercase() && token1 != token2
  }

Anyway as soon as I saw the problem I thought "this is either completely trivial or insanely difficult depending on whether you want proper unicode handling or not".

I haven't really thought about it but I doubt his solution is fully correct according to unicode. E.g. What happens with `aßSSb`? Who knows what should even happen in that case.

As for the malloc performance, MacOS has a significantly slower system memory allocator than Linux does. If you use jemalloc (https://crates.io/crates/jemallocator) instead I think you will see better performance than Javascript.

Good article anyway.

[ Parent | on HN ]

Re:Performance Showdown: Rust vs Javascript (2020) by mywittyname on Friday February 12, 2021 @02:07PM (#26117280)

Replacing the function call with this (and flipping the checks around) will probably improve performance as well.

I'd also be interesting in the performance improvements from replacing those to_lowercase() calls with a lookup from a static lookup array. Something like:

    if ( explosion_map[token1] == token2 )

There would need to be duplicates, explosion_map['a'] = 'A' and explosion_map['A'] = 'a'. But that's a small cost to pay for eliminating three function calls and two comparisons. As an added bonus, branch prediction will work really well on this strategy (since the majority of comparisons will have the same result). And doing that is a more of an actual language performance comparison, instead of a the standard library performance comparison this is.

[ Parent | on HN ]