2 ms·

The one caveat to this is that it's relatively easy to do large amounts of dynamic memory allocation/copying in C++ which can run worse than a scripted language

The one caveat to this is that it's relatively easy to do large amounts of dynamic memory allocation/copying in C++ which can run worse than a scripted language. Especially if you std::shared_ptr all the things, or do lots of things with std::string. I wrote a parsing algorithm in Java and C++, and the Java one was absurdly faster than the C++ one at one point because I was using std::vectors all over the place, so any time I needed to store an attribute in one of those it was doing memory allocation that was way slower than Java's memory allocation and I wasn't getting a lot of the benefit of C++ because of the memory indirections being similar to the Java version. Similarly doing a lot of += with std::strings will utterly destroy your performance due to all the allocations, deallocations, and copying. Expanding on strings a bit more: There's a really interesting attribute of a language like C++ versus one that has a GC and immutable strings. Because the memory lifetime is managed for you in a GCed language, there is effectively no need to actually copy string memory when handing it off to other libraries. Counter to that, because libraries have no idea what the lifetime of a string will be in C++, they effectively always have to copy strings in order to not have huge memory bugs. This actually leads to more performant code in the GCed language in this specific case due to there being less copying, without having some way to either modify the source of the other library or tell it in some way that the lifetime of the memory will always be good when it wants to access it. I think Rust lifetimes allow for similar optimization because it shouldn't compile if the memory gets deallocated while something else has a reference to it. Just an interesting observation I noticed a little while ago when working on heavy string processing code.

kibwen 4y ago
I'd say it's quite hard to make C++ approach the speed of Python even with heavy allocation and frequent copying. My ballpark is that Python code will be between 10 to 100 times slower than the equivalent C++ or Rust code. Java's an entirely different beast, and can definitely be on par with allocation-heavy C++, though you're not going to be writing Java functions that can be called from within Python. And your intuition about Rust is correct, there's no pressure to defensively copy strings in Rust as there is in C++, you can just safely pass and store the references.
- cyber_kinetist 4y ago
  Your C++ code can even be much slower than Python if you are not careful. Here's a good example of a StackOverflow question asking why it takes a longer time to split a string in C++ than in Python: https://stackoverflow.com/questions/9378500/why-is-splitting-a-string-slower-in-c-than-python https://stackoverflow.com/questions/9378500/why-is-splitting... Python's objects are ref-counted and stored on the heap, so copies do not happen unless you make it explicit. And Python's strings are all interned and stored in a single hashtable, so duplicate strings will not consume any more memory. These properties makes Python quite competitive with naively written C++/Rust. You can certainly write fast string in C++/Rust using string slices (std::string_view in C++ and &str in Rust), but in C++ you need to worry about any memory-related errors and in Rust you need to fight with the borrow checker. I also think that if you really want the best performance in C++/Rust then you need to write your own string class tailor-made to your problem.

kibwen 4y ago

I'd say it's quite hard to make C++ approach the speed of Python even with heavy allocation and frequent copying. My ballpark is that Python code will be between 10 to 100 times slower than the equivalent C++ or Rust code. Java's an entirely different beast, and can definitely be on par with allocation-heavy C++, though you're not going to be writing Java functions that can be called from within Python. And your intuition about Rust is correct, there's no pressure to defensively copy strings in Rust as there is in C++, you can just safely pass and store the references.

cyber_kinetist 4y ago
Your C++ code can even be much slower than Python if you are not careful. Here's a good example of a StackOverflow question asking why it takes a longer time to split a string in C++ than in Python: https://stackoverflow.com/questions/9378500/why-is-splitting-a-string-slower-in-c-than-python https://stackoverflow.com/questions/9378500/why-is-splitting... Python's objects are ref-counted and stored on the heap, so copies do not happen unless you make it explicit. And Python's strings are all interned and stored in a single hashtable, so duplicate strings will not consume any more memory. These properties makes Python quite competitive with naively written C++/Rust. You can certainly write fast string in C++/Rust using string slices (std::string_view in C++ and &str in Rust), but in C++ you need to worry about any memory-related errors and in Rust you need to fight with the borrow checker. I also think that if you really want the best performance in C++/Rust then you need to write your own string class tailor-made to your problem.