Follow

Don't obsess over performance of your code, obsess over making it readable and clear.

(in reference to my previous post)

@fribbledom That bit of not-easily-readable SQL we added to our app changed one request from 320ms to 2ms.

It did make sense to make it harder to read. It gets called too often for that to not matter.

@K0nrad

There are exceptions to every rule. If I want to formulate a rule, though, it's still that one.

Readability is #1.

@fribbledom @K0nrad The solution here is to use comments for what they were invented for: explaining WHY. Example:

This code is semantically equivalent to simpler query XYZ. But, X makes it run 300x slower (as of this date), and you cannot have YZ without X. For this reason, the following query is used, which provides the same service, is much faster/uses less memory/etc. It changing this query, make sure it remains compatible with XYZ.

@vertigo @fribbledom @K0nrad +1 on motivation in comments, I'm also really happy when people put stuff like that in commit messages.

@fribbledom Depends upon your requirements. It should be noted that those aren't always conflicting goals.

@fribbledom I disagree. Obsess over that your code actually works (reliability). Then make it work well (performance).

The “works” part requires that you write tests, which act as documentation for other programmers. Writing good tests pretty much require structuring code in a readable and understandable way. If you can then also write elegant and clear code, that’s just extra sugar on top.

Usually if you follow these rules, you end up with very readable code with the occasional optimization (probably less than 1% of the code base).

Bonus points for programmers who explain the why and how of optimizations with comments. :)

@fribbledom the person you help, when they come back to this code in 6 months, could be you

@patterfloof @fribbledom Many years ago, I went back to my own code (amusingly enough, yes it was 6 months later), and I couldn't figure out where to add a feature. THAT is when I got serious about comments, and I've never had that problem again.

I always test performance before spending any time on optimization. I had one script I was sure would be slow, and it averaged 0.3 seconds per test file; I had hoped for under 10 seconds... woo, already there, and faster!

@fribbledom

>> Don't obsess over performance
>> of your code

Code something to do the obsessing FOR you.

@fribbledom What if performance is actually important? Like if it gets run thousands of times a second?

@gudenau

There are always exceptions to rules. There's just got to be a good enough reason. If I want to formulate a rule, though, it's still this one.

@fribbledom I always try to strike a balance at least.

Probably the worst thing I do is use "<< 1" and related for multiplication and division where I can.

@fribbledom I always comment my code. I don't see why others don't even in a meta-sense of where a given function/method fits into the whole assembly. Short descriptors help a lot when working on something becoming increasingly complex.

@fribbledom Exactly, some months earlier, I was very impressed by some self-written code. Later, I discovered my documentation just sucks around this. That's why I was forced about to get rid of that codebase 😏

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!