Rust Programming Language RustConf 2021, 15 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: RustConf 2021 - The Importance of Not Over-Optimizing in Rust by Lily Mara

Description

The Importance of Not Over-Optimizing in Rust by Lily Mara

The Rust programming language has a lot of advanced features that enable some fantastic optimizations. For new Rust developers these can feel both exciting and constricting. Because Rust allows us to write highly-optimized code that we as experienced Rust developers can understand, it's tempting to do this all the time.

In this talk I will show that these optimizations are often unnecessary to get performance that beats highly dynamic languages like Python. For new Rust developers, breaking the temptation to over-optimize can lead to higher productivity and satisfaction with Rust.

A

Hi, my name is lily. I've been using rust for side projects since 2015 and professionally at one signal since 2019., I'd like to tell a short story about a new rust user who runs into some stumbling blocks during their learning journey and use that to jump into a discussion about how the community can better serve users like them meet jean jean is a python developer. Who's been writing software for several years. They're working on some json aggregation code in python and they've noticed that it's a performance bottleneck for their application.

A

They've heard that rust is very fast, so they decide to investigate moving it into rust. They find the cerade crate, which allows them to parse the json into easy to manage trucks and they're happy. The code seems pretty quick and they probably show it off to a more experienced rust developer.

A

The experienced developer tells gene that the code is okay, but it has some unnecessary allocations in it. It uses an own string on the data struct. It could be improved with the addition of lifetimes. Cere has support for deserializing borrowed strings instead of own strings, so you can save on a lot of allocations. They tell gene since they're excited about the prospect of writing high performance code. Gene leaves this conversation with the motivation to dive deep.

A

They haven't used lifetimes yet, but they do a lot of reading to try and figure it out after a lot of time and frustration. They have a solution that should be much more performant they've added a lifetime to the data struct. That certainly is using for parsing gene benchmarks, the performance of the new borrowing version against the original owning version. They run both of them against 1000 lines of json.

A

It seems like they made some meaningful performance improvements. The bars here represent the runtimes of the solutions relative to the fastest version. The fastest version is the rust code using references and the slower version is the rust code using own strings. This runs in around 1.5 x. The time of the faster version out of curiosity.

A

Gene also benchmarks, the original python code against both rust versions.

A

Oh after seeing these benchmarking results, gene is a bit confused. They just wanted to write something that was faster than python. After all, their original slow version is nearly 20 times faster than the python code, so why did they have to spend all that time? Learning these new topics now it may not seem like it if you've been writing rust for a while, but there are a lot of new ideas hiding in this struct definition.

A

If you wanted to understand this as a new rust developer, you would need to learn about lifetimes, which implies learning about generic arguments and references. References implies. Learning about ownership.

A

Ownership is famously one of the most difficult things for new rus developers to learn. Now it's just one of four difficult topics: that's facing gene if they want to be able to graduate from writing so-called slow rust code.

A

This is also an extremely simplified example where gene parses the data into a struct and immediately uses and discards it. If this were a larger example, they would need to add lifetime annotations to function, parameters and return, types info blocks and add them to any structs which contain instances of data they may spend a long time. Threading.

A

All of the lifetimes, through only to find out eventually that they can't do it, because a function somewhere in the program does not accept input that uses borrowed values lifetimes and generics are viral complexity for programs and adding them in one small place deep within the call stack can sometimes require adding them to tens or even hundreds of other places in the code.

A

Now at this point, there are a few ways that our story can go. Gene might see the value of the new skills they learned while tweaking the performance of their code. They may have found the novel memory model of rust, interesting and be intrigued to learn more.

A

They might also think that they spent a lot of time learning esoteric concepts only to get an improvement that wasn't significantly better than what they were already getting from their so-called bad code.

A

They might not see the long-term benefits of these things and focus in on the small performance difference relative to the large effort they put in different people will, of course, have different reactions in the same situation, but I would like to propose the idea that gene might have been able to delay these topics to a bit later in their rest journey.

A

Now I don't mean to make these topics out to be unapproachable terrors, but they do have a very real learning cost to them and presenting them as something that new developers need to tackle head on soon after starting increases the demands on new developers and puts barriers in place that can have negative repercussions throughout the community.

A

I'd like to propose instead that we'd encourage new rest developers to write more easy, rust or, you might even say bad rust. We should be encouraging people to write functions like this. This function uses two own strings when it could very easily take in two borrowed strings.

A

These borrows can be added on when it's really necessary. Now an experienced developer might be able to determine when and where these kind of borrows can be effectively used without having large effects on the program's complexity. A newer developer might try to add lifetimes and borrows to every heap allocated type in their code and get extremely frustrated.

A

I think we should all consider how rust looks to a new developer. This is a language that has a reputation for being very difficult to learn even for experienced people, and I don't think it needs to be that way.

A

New developers can sidestep a lot of the difficulty of the ownership and borrowing system by writing code that is slower to run but easier to understand. This trade-off between performance and ease of use is not unique to rust at all, but rust does have the unique benefit of naive code, often being fast enough.

A

We should be taking advantage of this benefit and leveraging it to allow new rust developers to become productive with rust more quickly.

A

These new developers might not be writing code, that's as fast as possible, but it will often beat dynamic languages and they should be more likely to stick with the language if they don't have huge barriers to adoption.

A

These topics are not going to go anywhere. They will always be there for the developers that really do care about performance, but the majority of people trying out rust for the first time can get away without them.

A

I'd like to close with a few tips that I think we should more quickly provide to new rest developers. Firstly pass around own values and not references. References are great, but they can open up a can of worms that many people are not expecting next use clone.

A

You can save on heap allocations by borrowing, of course, but does your 100 line cli program really need to save on allocations?

A

Maybe not, if you do find yourself in a situation where you need to save on heap allocation work, maybe try wrapping your type in an rc or an arc instead of standard references.

A

These are reference counted pointer types that allow you to share ownership between multiple variables, similar to how values work in garbage collected languages. Finally, and this one's important, if we want to hide the performance costs of the previous points, compile your code with the release flag. If you spent any time on russ communities like the subreddit or discord servers, you've probably seen someone complaining about rust being slow only to then become impressed with their performance after recompiling with optimizations turned on.

A

Thank you everyone. I hope that this talk inspires you to write less heavily optimized russ code and new developers to not worry so much about the performance.

A

If you're interested in speeding up your non-rust projects, through incremental edition of rust code check out my book refactoring to rest, the first four chapters are available now in early access on manning.com.