6 May
2017
6 May
'17
7:44 p.m.
On 6 May 2017 09:09 -0400, from cym224(a)gmail.com (Nemo):
True, optimized code can be difficult to read. But very little code
really _needs_ to be optimized to that level, and when you come across
it, you will generally know -- at least after running the application
through a profiler. (I have to admit we do have it easy these days.)
I've been working on optimizing some SQL code recently -- I know,
that's not exactly operating system kernel C or assembler -- and it's
amazing at times how the code can end up being both easier to
understand _as well as_ faster to execute, if you just put some
thought into what the code really needs to do. And not just minor
speedups either, but wallclock runtime reductions on the order of _two
to four nines_.
I think there's been only one time in the last several years when I
have really _needed_ to optimize code to the point that its workings
were not obvious.
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
I would
actually take that one step further: When you are writing
code, you are _first and foremost_ communicating with whatever human
will need to read or modify the code later.
..., there are
times when the code is transformed by optimization into something very
difficult to read. (We used noweb to document the transformation.)