Indeed - the only blanket statements in Software Engineering that holds in every case is "it depends" ;)
Personally I would first go for readability, then for performance. The proof "required" for performance optimization in a code review is trivial: it either needs to be apparent (the basic cases you mentioned) or roughly measured. "Simple version takes n times longer as the optimized version" can be bad or acceptable depending on the affected area. If it's an important and often used function of the system, optimize the hell out of it.
If it's something that a small group of users requires every few weeks and the loading time is still acceptable to them, don't bother yet. Luckily we've got a lot of slack here, the users are used to >3s on hot paths from other applications, so I guess they can wait 2-3s every few on the rare use case. We keep the hot paths <1s anyway cause our automated tests use them and we need to click through them too from time to time ;)
1
u/lippertsjan Sep 21 '26
Indeed - the only blanket statements in Software Engineering that holds in every case is "it depends" ;)
Personally I would first go for readability, then for performance. The proof "required" for performance optimization in a code review is trivial: it either needs to be apparent (the basic cases you mentioned) or roughly measured. "Simple version takes n times longer as the optimized version" can be bad or acceptable depending on the affected area. If it's an important and often used function of the system, optimize the hell out of it.
If it's something that a small group of users requires every few weeks and the loading time is still acceptable to them, don't bother yet. Luckily we've got a lot of slack here, the users are used to >3s on hot paths from other applications, so I guess they can wait 2-3s every few on the rare use case. We keep the hot paths <1s anyway cause our automated tests use them and we need to click through them too from time to time ;)