4 ms·

Today I had to debug code with some database calls within 5 levels (at least) of for-each loops. I stopped measuring at ~40,000 database round-trips. "Enginee

by eterm 12y ago

Today I had to debug code with some database calls within 5 levels (at least) of for-each loops. I stopped measuring at ~40,000 database round-trips. "Engineering time costs more than CPU time" was the attitude, and for the original problem in its original specification, the solution was clearly OK. But here we are, now needing to work out the original specifications, work out the current implementation (in case they differ anywhere), and work out whether it's worth re-writing it top-down or just fixing the worst of the loops. And I'm not blaming whoever wrote this originally, it must have done its job to make it into the code base, but it really sucks to have to unpick it because an assumption of "database calls are free" is an assumption that unravels in a really messy way.

detaro 12y ago
> now needing to work out the original specifications, work out the current implementation (in case they differ anywhere), and work out whether it's worth re-writing it top-down or just fixing the worst of the loops. That always seems to be the problem: refactoring is only cheap if you can be sure that your test coverage catches it if you break something. Of course, the code bases that need heavy refactoring probably don't have it, because otherwise they would have been improved already...
knightofmars 12y ago
"...for the original problem in its original specification, the solution was clearly OK." That statement leads me to believe this was technical debt that went unpaid and not a failing of design. Additionally, if your company is in a successful enough position to spend the time required to pay down this technical debt then if I were in your position I would count myself as lucky. "...it must have done its job to make it into the code base...", exactly right! Every time I hit one of these situations I view it as a way for me to, "Try and leave this code a little better than you found it." I'm all about making things easier for the next guy who comes along.
burkemw3 12y ago
I quickly learned that batching database and web service calls instead of making them inside a loop is generally not a premature optimization. It is one of the few performance considerations I consider while writing and reviewing code.

by eterm 12y ago

detaro 12y ago

> now needing to work out the original specifications, work out the current implementation (in case they differ anywhere), and work out whether it's worth re-writing it top-down or just fixing the worst of the loops. That always seems to be the problem: refactoring is only cheap if you can be sure that your test coverage catches it if you break something. Of course, the code bases that need heavy refactoring probably don't have it, because otherwise they would have been improved already...

knightofmars 12y ago

"...for the original problem in its original specification, the solution was clearly OK." That statement leads me to believe this was technical debt that went unpaid and not a failing of design. Additionally, if your company is in a successful enough position to spend the time required to pay down this technical debt then if I were in your position I would count myself as lucky. "...it must have done its job to make it into the code base...", exactly right! Every time I hit one of these situations I view it as a way for me to, "Try and leave this code a little better than you found it." I'm all about making things easier for the next guy who comes along.

burkemw3 12y ago

I quickly learned that batching database and web service calls instead of making them inside a loop is generally not a premature optimization. It is one of the few performance considerations I consider while writing and reviewing code.