Hacker News Reader

Comment by bakuninsbart | Hacker News Reader

I'm quite nooby in both Rust and C++, but for the little interactions I had, I felt like Rust had a much clearer path forward than C++ when I was in doubt, and "how to write in good style" was more obvious. This leads me to the assumption that building a Rust culture is probably easier than building a C++ culture, because it is easier to get junior developers and those coming from other languages up to speed.

View on HN

Yep. The one big beginner “mistake” I see people make in rust is overusing Box / String / Vec. Rust code that allocates everywhere can be even slower than javascript. The reason? Malloc is slower than you think. Slower than short allocations in V8 or Go. If you want performance, make friends with &str, &[], <I: Iterator<…>>, bumpalo, SmartString and SmallVec. (Or similar crates). Removing allocations from the hot path can improve performance by 10-100x.

That said, most code isn’t a hot path. Performance doesn’t matter in most programs. And if you’re a veteran C++ programmer, none of this will come as a surprise.

I slightly disagree. Using heap allocated types is perfectly fine. The biggest thing I have to keep reminding myself coming from higher level languages is to re-use data structures, and to architect things in a way that this is possible.

Allocating a new String/Vec every single time you do something is killer for performance, but if you do it once up front then clear the data structure for the next use it should be performant enough.

> re-use data structures

That's funny. I've been going mostly the other direction. I'm avoiding mutable structures whenever possible. I have a much easier time reasoning about stuff when I know that things aren't going to change mid-life.

I don't know what you're programming, but it's pretty hard to not use more complex structures like Vecs and HashMaps without them being mutable.

Also, that is exactly what Rust's borrow-checker is there for. It doesn't allow you to mutably borrow the same data structure multiple times.

I was thinking more about the things being contained rather than the containers themselves. But you're right - they are all data structures.

That is certainly true, but if you are talking about things that are too big to stack allocate, the cognitive overhead of reusing heap allocated items is the price for getting back the throughput overhead of memory allocation.

> Slower than short allocations in V8 or Go

Slower than V8, definitely possible. Slower than Go, very unlikely, since it doesn't have a generational or compacting gc.

For some reason I always assume Go is faster than Javascript+V8. Is that actually true?

Does anyone know of any guide/tutorials/books about how to avoid common Rust performance issues. Like real world examples, "instead of doing X, do Y". I am maybe beginner to intermediate in Rust, but I think I'm still very susceptible to those things.

I've observed some level premature optimization in the Rust community, surely coming from being performance oriented.

I received a review comment some time ago about changing a line of code in order to spare one allocation, for a call that was executed _once_ in the whole lifetime of a program. That was not the only time I've observed this attitude.

I think starting with being handy with profiling and only after measurement, thinking about solutions, rather than starting with the idea that certain patterns are harmful per se.

The Rust Performance Book - https://nnethercote.github.io/perf-book/.

Same here. Clippy and rust compiler made me switch to Rust from c++. Now after experiencing cargo, I find python to be insufferable (tooling, not the language).

I’m always fretting I haven’t written good code no matter what language I write in. But the Rust compiler + linter (clippy) make me fret a bit less.

Reply on news.ycombinator.com