I chose to rewrite the ideas Casey presented in the video in Rust, trying to be idiomatic is not really the goal of the solutions you’ll see below, but rather experiment with how structuring the code may lead to a big performance penalty.

All the code I reference in this post is available in this Gist.

You can also check this awesome video by @lavafroth, that goes over this article and further explains some areas I might have missed: Two Decades of Hardware Optimizations Down The Drain

Base Case: Traits

Starting with all the “Clean” Code principles, we would likely implement something that looks like the code seen below:

 1trait Shape {
 2    fn area(&self) -> f32;
 3}
 4
 5struct Square {
 6    side: f32,
 7}
 8
 9impl Shape for Square {
10    fn area(&self) -> f32 {
11        self.side * self.side
12    }
13}
14
15// ... the same for Rectangle, Triangle and Circle

Running the accumulator test Casey shows in the video, yields us a runtime of 54,956 ns/iter for 10240 items (more detailed information on the annex down below). We’ll use this as our baseline going forward.

 1    #[bench]
 2    fn total_area(b: &mut Bencher) {
 3        let shapes: Vec<Box<dyn Shape>> = init(COUNT);
 4
 5        b.iter(|| {
 6            let mut accum = 0f32;
 7            for shape in &shapes {
 8                accum += shape.area();
 9            }
10
11            accum
12        });
13    }

If you’re more familiar with Rust you’ll immediately catch the use of Box there as a possible location for optimization. For our constraints, we do need to box the values when constructing them as we need to have a “polymorphic list”, and because we’re using a trait as our abstraction for Shape, the values of our shapes vec are of unknown size to the compiler.

Our first performance gain comes without touching much of the implementation code, but rather, the code in the “caller” side (the benchmark function). Using 4 accumulators instead of one:

 1    #[bench]
 2    fn total_area_sum4(b: &mut Bencher) {
 3        let shapes: Vec<Box<dyn Shape>> = init(COUNT);
 4
 5        b.iter(|| {
 6            let mut accum1 = 0f32;
 7            let mut accum2 = 0f32;
 8            let mut accum3 = 0f32;
 9            let mut accum4 = 0f32;
10
11            let count = COUNT / 4;
12            let mut iter = 1;
13            while count - iter > 0 {
14                accum1 += shapes[iter * 4].area();
15                accum2 += shapes[1 + (iter * 4)].area();
16                accum3 += shapes[2 + (iter * 4)].area();
17                accum4 += shapes[3 + (iter * 4)].area();
18
19                iter += 1;
20            }
21
22            accum1 + accum2 + accum3 + accum4
23        });
24    }

This improves on the baseline by 3.1x, executing at a runtime of 17,725 ns/iter. Why? A better utilization of CPU cycles. Modern CPUs are able to handle parallel computations such as the one done above, but the compiler may not take advantage of this if they’re not easily recognizable.

Of course, the code above is not really something we can easily copy paste and use in other solutions because there are a lot of assumptions we need to hold, the biggest one being: Is count divisible by 4? But that is besides the point, as we’re mostly bit twiddling here.

Still Idiomatic: Match

Going forward, Casey then breaks the “Polymorphism Rule” of “Clean” Code, and writes the same implementation using a switch statement. In idiomatic Rust, we can equate that to a match on a enum.

 1enum Shape {
 2    Square { side: f32 },
 3    Rectangle { width: f32, height: f32 },
 4    Triangle { base: f32, height: f32 },
 5    Circle { radius: f32 },
 6}
 7
 8impl Shape {
 9    fn area(&self) -> f32 {
10        match self {
11            Shape::Square { side } => side * side,
12            Shape::Rectangle { width, height } => width * height,
13            Shape::Triangle { base, height } => 0.5f32 * base * height,
14            Shape::Circle { radius } => PI * radius * radius,
15        }
16    }
17}

The code here is still very readable, follows some very good conventions and is something that you’d see every day in Rust. There is a drawback of this implementation if you’re writing a library: the dependents of said library would not be able to extend the Shape system and add a Hexagon for example.

With the code structured this way, we see a whopping 3.2x improvement from the baseline when using the regular for loop, and a massive 8.5x improvement when using the _sum4 variant (17,141 ns/iter and 6,434 ns/iter).

This is the knowledge I’ll take from this experiment the most, because this is still very idiomatic code, and knowing this performance difference is beneficial when tackling performance critical code. This is where I can see most value from the “Performance-aware Programming” that Casey advocates for.

My assumptions is that the performance gains here come mostly from the removal of the Box construct. Having the shapes represented as enum variants instead of trait implementors makes their size known at compile time and reduces the need of the Box to represent a “polymorphic list” (using quotes here is very applicable, because this is not really a “polymorphic list” on the original sense of the word).

Breaking with Idiomatic Rust: Lookup Table

Moving forward with the optimizations we then come across using a lookup table for the multiplier constants. If you look closely at the match code above, you’ll notice a pattern. Casey mentions this pattern in his video and also claims that moving the code out of the Polymorphic variant and into the if-else/switch style (or in our case the match style) highlights this pattern.

Trying to still maintain some semblance of idiomatic Rust, I went with a different approach for the lookup table, using a constructor function for Shapes and storing the multiplier within the struct itself. This leaves us with:

 1enum ShapeType {
 2    Square { side: f32 },
 3    Rectangle { width: f32, height: f32 },
 4    Triangle { base: f32, height: f32 },
 5    Circle { radius: f32 },
 6}
 7
 8struct Shape {
 9    multiplier: f32,
10    width: f32,
11    height: f32,
12}
13
14impl Shape {
15    fn new(shape_type: ShapeType) -> Self {
16        match shape_type {
17            ShapeType::Square { side } => Shape {
18                multiplier: 1f32,
19                width: side,
20                height: side,
21            },
22            // ... the same for Rectangle, Triangle and Circle
23        }
24    }
25
26    fn area(&self) -> f32 {
27        self.multiplier * self.width * self.height
28    }
29}

Styling the code this way allows us to create shapes like so:

1let shape = Shape::new(Square { side: 2f32 }) // Shape::Square { side: 2f32 }

This is not so different from what we saw in the more idiomatic examples using traits and match.

This code is 6.4x faster than the baseline using the simple benchmark and 11x faster using the _sum4 variant. In this example, we can see that the sizes are known at compile time and there’s probably some other optimization of the instruction sent to the CPU that I’m not aware of.

Breaking the “small functions” principle: corner_area

To break the “small functions that only do a single thing” mantra from “Clean” Code, Casey introduces a CornerCont() information to the Shape struct. The resulting value should be 1 / (1 + shape.CornerCount() + shape.Area()).

Implementation wise they are very similar from what we’ve seen so far, and the performance gains we seen before were also observed when calculating with the corner.

The base case yielded a runtime of 54,302 ns/iter. Changing the trait implementation into a match statement, we see the performance jumping 4.4x this time (interestingly we don’t see that much difference in the _sum4 variants, see the annex for more information). The lookup table implementation took the performance to new levels with a performance boost of 6.4x with the naive for and once again by 11x with the _sum4 variant.

Conclusion

Even though most of what we seen here is hardcore bit twiddling, being a “Performance-aware Programmer” is not a bad thing. Most of the people reading this (and me writing!) will most likely be developing Software that does not necessarily needs to make these trade-offs for performance, but that’s not the point, at least not for me.

The point is: we should be aware of them!

We should always be aware when we’re doing trade-offs and we should strive to learn new things that challenge our status quo.

I’ll probably not directly use many of the constructs I went through in this post in my day-to-day job, but it sure as hell was fun researching and quickly doing them this Sunday evening!

Annex 1: Benchmark Results

For all the results we’ve seen thus far in this post, I used a Vec::with_capacity(10240) and the cargo bench command, below you can see the execution times:

$ cargo bench -- total_area
   Compiling clean_code v0.1.0 (/home/chrs/Workspace/clean_code)
    Finished `bench` profile [optimized] target(s) in 0.58s
     Running unittests src/lib.rs (target/release/deps/clean_code-3affde07f20d1563)

running 8 tests
test m01_trait::tests::total_area                  ... bench:      54,956 ns/iter (+/- 280)
test m01_trait::tests::total_area_sum4             ... bench:      17,725 ns/iter (+/- 1,373)
test m02_match::tests::total_area                  ... bench:      17,141 ns/iter (+/- 304)
test m02_match::tests::total_area_sum4             ... bench:       6,434 ns/iter (+/- 5,001)
test m03_table::tests::total_area                  ... bench:       8,560 ns/iter (+/- 169)
test m03_table::tests::total_area_sum4             ... bench:       5,734 ns/iter (+/- 1,005)
test m04_table_multiplier::tests::total_area       ... bench:       8,555 ns/iter (+/- 29)
test m04_table_multiplier::tests::total_area_sum4  ... bench:       5,002 ns/iter (+/- 82)

$ cargo bench -- corner_area
    Finished `bench` profile [optimized] target(s) in 0.01s
     Running unittests src/lib.rs (target/release/deps/clean_code-3affde07f20d1563)

running 8 tests
test m01_trait::tests::corner_area                 ... bench:      54,302 ns/iter (+/- 233)
test m01_trait::tests::corner_area_sum4            ... bench:      35,922 ns/iter (+/- 563)
test m02_match::tests::corner_area                 ... bench:      12,160 ns/iter (+/- 2,019)
test m02_match::tests::corner_area_sum4            ... bench:      12,128 ns/iter (+/- 41)
test m03_table::tests::corner_area                 ... bench:       8,554 ns/iter (+/- 23)
test m03_table::tests::corner_area_sum4            ... bench:       5,736 ns/iter (+/- 15)
test m04_table_multiplier::tests::corner_area      ... bench:       8,547 ns/iter (+/- 10)
test m04_table_multiplier::tests::corner_area_sum4 ... bench:       4,995 ns/iter (+/- 6)

test result: ok. 0 passed; 0 failed; 0 ignored; 8 measured; 8 filtered out; finished in 5.24s

You’ll see a m03_table that has been omitted on the blog post just due to it being very similar to the m04_table_multiplier, the m03 module was my first naive translation of the lookup table optimization (I’ve left in the gist if you’re curious).

I’ve been recently been bit with the writing bug again, but I don´t know how long this will last (you can check for yourself how long ago was the last post on this blog, and more importantly it was the only one that survived).

Reading my previous post had me thinking about my career so far and how writing can preserve my thoughts at a point in time, and generally make for a pretty interesting read on the future. My memory isn’t the best, and I tend to think writing to bve the best medium to preserve my thoughts for myself.

The year is 2019

At that time, I was employed at Biggy, working with e-commerce recommendation engines, which was my first real programming job, as stated in that post. I’m still at the same company kinda. That year was also a pivotal moment in my career, and Biggy’s journey, being exactly the year when it was acquired by VTEX, my current employer.

That year also marked several personal milestones: I traveled abroad for the first time (twice!), my nephew was just born (he’s now almost 5 years old) and the world was yet to see what the word pandemic meant. My first international trip was also something I wish I had a better recollection of, as it was part of my interview process for Spotify, which ended with me not landing the job, but learning a lot throughout the process.

Fast-forward 5 years

If I answered “how do you see yourself in 5 years?” back then, would the answer be close to the reality of today? Mostly no. But that doesn’t mean I didn’t accomplish things I was hoping for, it actually means I accomplish things I did not foresaw. This may be an improvement or not, I won’t get too hanged up on that.

A big part of that journey was due to VTEX and the people I work with on a daily basis. Being part of a welcoming team and working with interesting problems made it very difficult to accept any huge changes (and there were opportunities for some of those).

Something that held me in place for some time was my academic journey. Graduating for me was a slow process, as I was already working, sometimes I got very disgruntled with the classes and assignments. It was actually the pandemic that made me focus a bit more in my studies, but the full-fledged graduated status only came in the near end of those 5 years.

Living abroad has been a big dream of mine, and maybe the strongest difference from my ideal self of 5 years ago. I hadn’t been giving that much thought to this since recently, and it’s something that I’m setting my eyesight on for the near future.

What does the next 5 years hold?

I can’t predict the future, but I’m certain my current actions will help shape it, and one thing that I can do is control my current actions. My last years have been a cruise in order to reach some sort of financial security, and I few that the time has come to lean on that security and take more risks.

I’m pretty confident that the work I like to do is coding, as simple as that, and I’ll try to optimize this on the opportunities going forward. That means I’m most likely not follow a management path in the near future, and set my sights on improving myself as a specialist. This has been something that I’ve poured a lot of thought into, and I find myself more certain than ever about this path.

Another thing that is crucial to me is self-improvement through working on my body. There are lots of people out there that have given general wisdom about mind and body being connected, so I won’t be adding much to that discussion (and I don’t have significant knowledge to do so). But what I can say is that working out and practicing sports has been a beneficial hobby, for my mind and body.

And I dare finish with: I should write more. I like writing and, moreover, I like reading my thoughts at a later point. So Iĺl try to document what I find interesting and have been working on as learning projects, but also, maintaining a healthy check-up of what is on my mind.

This should’ve probably be a disclaimer at the top, but I’ll leave it here: the writing here is the definition of rambling. I wrote what came up at the top of my head without much thought, and this will probably have use only for me in the future.

Fast-forward 12 years in the future, two years into the best job I could ever hope for, a lot learned along the way and a lot more to learn in the future. Two years might not seem like a lot, but working for a startup made a lot of difference, being exposed to new technologies and having people to support me while I was learning.

Knowing that you don’t know

Looking back with the power of hindsight my biggest lesson was that there is so much I don’t actually know. At that time I had been programming for 10 years, if you call the first few years as actually programming, I had tested the waters with Java, C, C++ and occasionally web development.

The main focus of most of my time learning was to create a game that I would enjoy and call mine, quite common among gamers that go into programming. But a mistake I repeated time and time again was to doubt my own abilities. I would start over 100 times, trying to find a better solution, watched hundreds of videos and tutorials, but always beginner level, and that was my biggest mistake, not exposing myself to more advanced programming made me stagnant for a long time.

Do… or do not. There is no try.

* Tutorials are great, but actually doing stuff is even better.

The tipping point of my programming career came in the form of Open Source software, two years into my undergrad I enrolled in a program to “foster open source software development”, that was the first time I had to tackle a codebase larger than a dozen files, with a clear goal and being exposed to code that wasn’t written by me. A couple months after that I landed my first real programming job.

Knowing how to search what you don’t know

One of the most important tools of the job has to be Google (or DDG!), but it’s one of the hardest to actually get it right, knowing what and how to ask something is actually more important than trying, and failing, to know everything by heart, don’t get me wrong, there are a lot of tasks that are deeply ingrained in your memory and you will be able to correctly execute them till the end of your life, but the rest you should google.

So, how do you look for something online? My first instinct when I try to find something is to actually find someone that went through the problem I’m having right now and how they fixed it, most likely ending up reading a question in Stack Overflow. The search query could be either the error message or an imagination of how that question would be asked by somebody else, like “how to pad strings in javascript?”. These types of questions will most likely yield better result when you know very well what you’re trying to accomplish, and sometimes knowing lingo, and that’s the hardest part.