Optimising code is an art. Designing a perfectly optimised algorithm is a slow, methodical process which really forces you to understand the problem you're trying to solve. You have to know your input -- not just the theoretical format it is in, but what realistic instances of it will look like. By prioritising common cases, you can decrease your average runtime. Likewise, choosing the right output format is difficult—you have to balance the efficiency of generating the output with the ease of extracting information from it. This is a really enjoyable process to me.
The drawback of optimisation is that it might not be worth it. I enjoy optimizing code because high performance is fun, but also because I want software to be more resource-efficient. An optimized program uses more CPU resources and so is more power-hungry, but the decrease in runtime results in a net reduction in energy consumption. But this doesn't matter if users will spend the additional time they have on running more instances of the program. For use cases like cryptocurrency and machine learning, where the amount of computation we perform is growing unboundedly, optimization may actually increase energy consumption.
I'm always taking suggestions for projects which don't suffer from this trade-off. The best idea I have thus far is compiler architecture: a better compiler might make it easier for programmers to write more code (and thus to compile more often), but I expect this to have a net benefit. I like both C and Rust for different reasons, but optimal compiler architectures for the two would look entirely different, and I'm curious about both of them. I've written in more depth about flcc, the C compiler project and krabby, the Rust compiler project.
I also have a glossary of concepts for high-performance programming that I refer to in my writings here.