performance vs. readability/maintability

[Daniel Billingsley]

In another online group in which I participate, we were discussing a
particular piece of code that had a pretty high risk for breaking in the
future (because it depended on something not changing that was outside the
developer's control) but was slightly more performant. One participant
posted:

"I tend to take the performance track also, adding readability if the impact
isn't too great. There is also an odd reality that takes place even in the
software field however. Not sure I can explain it too well but simply said,
if you write code to handle the effects of changing the ordinal position of
a field, some other error will surface anyway."

which I found to be ridiculous to the point of being dangerous.

I know this is somewhat one of those opinion issues, but I just wondered
where everyone fell on the continuum.

[Mickey Williams]

Re: performance vs. readability/maintability

Personally, I prefer to write code that's readable and maintainable first
(modulo obvious perf wins like StringBuilder and DataReader in some
scenarios). After the code works, use a profiler to look for performance
bottlenecks. Having said that, I've often built prototypes for the purpose
of profiling perf . It's my experience that most people that obsess over
perf without profiling optimize in the wrong places and have butt-ugly
non-maintainable code.

--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press

https://www.servergeek.com

"Daniel Billingsley" <dbillingsley@N O.durcon.SPAAMM .com> wrote in message
news:e5Hr8PT1DH A.2680@TK2MSFTN GP11.phx.gbl...[color=blue]
> In another online group in which I participate, we were discussing a
> particular piece of code that had a pretty high risk for breaking in the
> future (because it depended on something not changing that was outside the
> developer's control) but was slightly more performant. One participant
> posted:
>
> "I tend to take the performance track also, adding readability if the[/color]
impact[color=blue]
> isn't too great. There is also an odd reality that takes place even in[/color]
the[color=blue]
> software field however. Not sure I can explain it too well but simply[/color]
said,[color=blue]
> if you write code to handle the effects of changing the ordinal position[/color]
of[color=blue]
> a field, some other error will surface anyway."
>
> which I found to be ridiculous to the point of being dangerous.
>
> I know this is somewhat one of those opinion issues, but I just wondered
> where everyone fell on the continuum.
>
>[/color]

[J.Marsch]

Re: performance vs. readability/maintability

For what it's worth I would almost always side with reliability. I hate
fixing code, especially when it's due to a bad decision on my behalf. I
suppose that if I were in a situation where some code absolutely had to run
faster (show-stopper), and the modification was the only way to get over the
line, and the reliability problem was not random, but a maintenance issue,
(only a bug if the table structure changes), and the reliability problem
would not cause more damage than running too slow..

Then maybe I would bring it up in a meeting, just so that my coworkers could
talk me out of it.

Regards

"Daniel Billingsley" <dbillingsley@N O.durcon.SPAAMM .com> wrote in message
news:e5Hr8PT1DH A.2680@TK2MSFTN GP11.phx.gbl...[color=blue]
> In another online group in which I participate, we were discussing a
> particular piece of code that had a pretty high risk for breaking in the
> future (because it depended on something not changing that was outside the
> developer's control) but was slightly more performant. One participant
> posted:
>
> "I tend to take the performance track also, adding readability if the[/color]
impact[color=blue]
> isn't too great. There is also an odd reality that takes place even in[/color]
the[color=blue]
> software field however. Not sure I can explain it too well but simply[/color]
said,[color=blue]
> if you write code to handle the effects of changing the ordinal position[/color]
of[color=blue]
> a field, some other error will surface anyway."
>
> which I found to be ridiculous to the point of being dangerous.
>
> I know this is somewhat one of those opinion issues, but I just wondered
> where everyone fell on the continuum.
>
>[/color]

[Jon Skeet [C# MVP]]

Re: performance vs. readability/maintability

Daniel Billingsley <dbillingsley@N O.durcon.SPAAMM .com> wrote:

<snip>
[color=blue]
> I know this is somewhat one of those opinion issues, but I just wondered
> where everyone fell on the continuum.[/color]

As I suspect many readers know already, I would code for readability
first, performance later, almost always.

Having said that, I will of course use a StringBuilder to create a
string over the course of a loop etc.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[J.Marsch]

Re: performance vs. readability/maintability

I agree with you. Sacrificing readability and reliability for a negligent
gain in performance _is_ ludicrous.

I am only slightly more flexible with the readability part. I will confess
that there have been a few times in my career where I had to sacrifice some
readability in order to eak out some extra performance.

In all cases, it was a situation where a perf deficit was magnified because
the code was either in a loop or was called extremely often, and where the
perf difference was vital to the acceptability of the application. (where
the perf difference was meaningful)

Beyond those exceptional instances, it seems to always pay off to go with
maintainability and reliability. You might get some quick notoriety if the
application runs a little faster, but in the long run, customers always seem
to appreciate the app that never crashes/never convolutes or loses their
data/etc over the one that runs really fast when it works at all.

"Daniel Billingsley" <dbillingsley@N O.durcon.SPAAMM .com> wrote in message
news:ewiUytU1DH A.4060@TK2MSFTN GP11.phx.gbl...[color=blue]
> Yeah the quote I posted actually makes two points
>
> 1) readability vs. performance
> 2) reliability vs. performance
>
> with the author says he chooses performance in both cases.
>
> My basic position tends to be that in most cases the performance[/color]
differences[color=blue]
> we're talking about our trivial (the tests used to demonstrate them often
> use 10,000,000 iterations and our code is doing exactly one per hour, for
> example). I can't see any wisdom whatsoever in obsessing over such[/color]
trivial[color=blue]
> performance gains and sacrificing what may well be hours of future work on
> the code.
>
> As far as the reliability, I think the position of writing code that is
> pretty likely to break some day because it performs slightly better is[/color]
just[color=blue]
> ludicrous. In this particular case, it was in the context of database
> access, which I think will far overshadow any milliseconds saved here or
> there by writing theoretically perfect code.
>
> "J.Marsch" <jeremy@ctcdeve loper.com> wrote in message
> news:ekQteEU1DH A.540@tk2msftng p13.phx.gbl...[color=green]
> > For what it's worth I would almost always side with reliability. I hate
> > fixing code, especially when it's due to a bad decision on my behalf. I
> > suppose that if I were in a situation where some code absolutely had to[/color]
> run[color=green]
> > faster (show-stopper), and the modification was the only way to get over[/color]
> the[color=green]
> > line, and the reliability problem was not random, but a maintenance[/color][/color]
issue,[color=blue][color=green]
> > (only a bug if the table structure changes), and the reliability problem
> > would not cause more damage than running too slow..
> >
> > Then maybe I would bring it up in a meeting, just so that my coworkers[/color]
> could[color=green]
> > talk me out of it.
> >
> > Regards[/color]
>
>[/color]

[Bruno Jouhier [MVP]]

Re: performance vs. readability/maintability

I'll follow the trend in the other replies: Readability and maintainability
have highest priority.

Like Mickey, I will only sacrifice readability for performance if I have
identified the performance bottleneck with a profiler and if there is no
other way to improve it.

I don't like the idea of introducing low-level optimization hacks "a
priori". I cannot find one example where this approach really worked and
brought benefits, but lots of examples where it did not work at all. On the
other hand, spending time on choosing the right data structures (so that
everything that you will access over and over will be properly indexed in
your object graphs) and the right algorithms really pays off.

Also, I am very careful in the way I use the language constructs, trying to
make the code as easy to read as possible, and as robust as possible, and
usually, I can find elegant solutions that don't conflict with the
performance goal. They may not give the absolute best performance
(otherwise, I would be writing in C, or even worse, assembly), but they
usually give a very good balance between clarity and performance.

Bruno.

"Daniel Billingsley" <dbillingsley@N O.durcon.SPAAMM .com> a écrit dans le
message de news:e5Hr8PT1DH A.2680@TK2MSFTN GP11.phx.gbl...[color=blue]
> In another online group in which I participate, we were discussing a
> particular piece of code that had a pretty high risk for breaking in the
> future (because it depended on something not changing that was outside the
> developer's control) but was slightly more performant. One participant
> posted:
>
> "I tend to take the performance track also, adding readability if the[/color]
impact[color=blue]
> isn't too great. There is also an odd reality that takes place even in[/color]
the[color=blue]
> software field however. Not sure I can explain it too well but simply[/color]
said,[color=blue]
> if you write code to handle the effects of changing the ordinal position[/color]
of[color=blue]
> a field, some other error will surface anyway."
>
> which I found to be ridiculous to the point of being dangerous.
>
> I know this is somewhat one of those opinion issues, but I just wondered
> where everyone fell on the continuum.
>
>[/color]

[Bruno Jouhier [MVP]]

Re: performance vs. readability/maintability

Yes. And I would certainly not hire the guy who wrote the original post and
believes in writing code that depends on the ordinal position of fields. No
way!

Bruno.

"J.Marsch" <jeremy@ctcdeve loper.com> a écrit dans le message de
news:etIJe1U1DH A.2604@TK2MSFTN GP09.phx.gbl...[color=blue]
> I agree with you. Sacrificing readability and reliability for a negligent
> gain in performance _is_ ludicrous.
>
> I am only slightly more flexible with the readability part. I will[/color]
confess[color=blue]
> that there have been a few times in my career where I had to sacrifice[/color]
some[color=blue]
> readability in order to eak out some extra performance.
>
> In all cases, it was a situation where a perf deficit was magnified[/color]
because[color=blue]
> the code was either in a loop or was called extremely often, and where the
> perf difference was vital to the acceptability of the application. (where
> the perf difference was meaningful)
>
> Beyond those exceptional instances, it seems to always pay off to go with
> maintainability and reliability. You might get some quick notoriety if[/color]
the[color=blue]
> application runs a little faster, but in the long run, customers always[/color]
seem[color=blue]
> to appreciate the app that never crashes/never convolutes or loses their
> data/etc over the one that runs really fast when it works at all.
>
> "Daniel Billingsley" <dbillingsley@N O.durcon.SPAAMM .com> wrote in message
> news:ewiUytU1DH A.4060@TK2MSFTN GP11.phx.gbl...[color=green]
> > Yeah the quote I posted actually makes two points
> >
> > 1) readability vs. performance
> > 2) reliability vs. performance
> >
> > with the author says he chooses performance in both cases.
> >
> > My basic position tends to be that in most cases the performance[/color]
> differences[color=green]
> > we're talking about our trivial (the tests used to demonstrate them[/color][/color]
often[color=blue][color=green]
> > use 10,000,000 iterations and our code is doing exactly one per hour,[/color][/color]
for[color=blue][color=green]
> > example). I can't see any wisdom whatsoever in obsessing over such[/color]
> trivial[color=green]
> > performance gains and sacrificing what may well be hours of future work[/color][/color]
on[color=blue][color=green]
> > the code.
> >
> > As far as the reliability, I think the position of writing code that is
> > pretty likely to break some day because it performs slightly better is[/color]
> just[color=green]
> > ludicrous. In this particular case, it was in the context of database
> > access, which I think will far overshadow any milliseconds saved here or
> > there by writing theoretically perfect code.
> >
> > "J.Marsch" <jeremy@ctcdeve loper.com> wrote in message
> > news:ekQteEU1DH A.540@tk2msftng p13.phx.gbl...[color=darkred]
> > > For what it's worth I would almost always side with reliability. I[/color][/color][/color]
hate[color=blue][color=green][color=darkred]
> > > fixing code, especially when it's due to a bad decision on my behalf.[/color][/color][/color]
I[color=blue][color=green][color=darkred]
> > > suppose that if I were in a situation where some code absolutely had[/color][/color][/color]
to[color=blue][color=green]
> > run[color=darkred]
> > > faster (show-stopper), and the modification was the only way to get[/color][/color][/color]
over[color=blue][color=green]
> > the[color=darkred]
> > > line, and the reliability problem was not random, but a maintenance[/color][/color]
> issue,[color=green][color=darkred]
> > > (only a bug if the table structure changes), and the reliability[/color][/color][/color]
problem[color=blue][color=green][color=darkred]
> > > would not cause more damage than running too slow..
> > >
> > > Then maybe I would bring it up in a meeting, just so that my coworkers[/color]
> > could[color=darkred]
> > > talk me out of it.
> > >
> > > Regards[/color]
> >
> >[/color]
>
>[/color]

[Jon Skeet [C# MVP]]

Re: performance vs. readability/maintability

Daniel Billingsley <dbillingsley@N O.durcon.SPAAMM .com> wrote:[color=blue]
> Yeah the quote I posted actually makes two points
>
> 1) readability vs. performance
> 2) reliability vs. performance
>
> with the author says he chooses performance in both cases.[/color]

Good grief.
[color=blue]
> My basic position tends to be that in most cases the performance differences
> we're talking about our trivial (the tests used to demonstrate them often
> use 10,000,000 iterations and our code is doing exactly one per hour, for
> example). I can't see any wisdom whatsoever in obsessing over such trivial
> performance gains and sacrificing what may well be hours of future work on
> the code.[/color]

Agreed.
[color=blue]
> As far as the reliability, I think the position of writing code that is
> pretty likely to break some day because it performs slightly better is just
> ludicrous. In this particular case, it was in the context of database
> access, which I think will far overshadow any milliseconds saved here or
> there by writing theoretically perfect code.[/color]

Yup. This is the problem I have with the oft-quoted performance article
(http://tinyurl.com/hxo2) which includes the following:

<quote>
Don't do it. Instead, stand up and pledge along with me:

"I promise I will not ship slow code. Speed is a feature I care
about. Every day I will pay attention to the performance of my code. I
will regularly and methodically measure its speed and size. I will
learn, build, or buy the tools I need to do this. It's my
responsibility. "

(Really.) So did you promise? Good for you.

So how do you write the fastest, tightest code day in and day out? It
is a matter of consciously choosing the frugal way in preference to the
extravagant, bloated way, again and again, and a matter of thinking
through the consequences. Any given page of code captures dozens of
such small decisions.
</quote>

I don't *want* to write the fastest, tightest code. I want to write
reliable, maintainable code, which performs *well enough*.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[J.Marsch]

Re: performance vs. readability/maintability

No kidding! That's just bad form.

"Bruno Jouhier [MVP]" <bjouhier@clu b-internet.fr> wrote in message
news:uk43B9U1DH A.3436@tk2msftn gp13.phx.gbl...[color=blue]
> Yes. And I would certainly not hire the guy who wrote the original post[/color]
and[color=blue]
> believes in writing code that depends on the ordinal position of fields.[/color]
No[color=blue]
> way!
>
> Bruno.
>
> "J.Marsch" <jeremy@ctcdeve loper.com> a écrit dans le message de
> news:etIJe1U1DH A.2604@TK2MSFTN GP09.phx.gbl...[color=green]
> > I agree with you. Sacrificing readability and reliability for a[/color][/color]
negligent[color=blue][color=green]
> > gain in performance _is_ ludicrous.
> >
> > I am only slightly more flexible with the readability part. I will[/color]
> confess[color=green]
> > that there have been a few times in my career where I had to sacrifice[/color]
> some[color=green]
> > readability in order to eak out some extra performance.
> >
> > In all cases, it was a situation where a perf deficit was magnified[/color]
> because[color=green]
> > the code was either in a loop or was called extremely often, and where[/color][/color]
the[color=blue][color=green]
> > perf difference was vital to the acceptability of the application.[/color][/color]
(where[color=blue][color=green]
> > the perf difference was meaningful)
> >
> > Beyond those exceptional instances, it seems to always pay off to go[/color][/color]
with[color=blue][color=green]
> > maintainability and reliability. You might get some quick notoriety if[/color]
> the[color=green]
> > application runs a little faster, but in the long run, customers always[/color]
> seem[color=green]
> > to appreciate the app that never crashes/never convolutes or loses their
> > data/etc over the one that runs really fast when it works at all.
> >
> > "Daniel Billingsley" <dbillingsley@N O.durcon.SPAAMM .com> wrote in[/color][/color]
message[color=blue][color=green]
> > news:ewiUytU1DH A.4060@TK2MSFTN GP11.phx.gbl...[color=darkred]
> > > Yeah the quote I posted actually makes two points
> > >
> > > 1) readability vs. performance
> > > 2) reliability vs. performance
> > >
> > > with the author says he chooses performance in both cases.
> > >
> > > My basic position tends to be that in most cases the performance[/color]
> > differences[color=darkred]
> > > we're talking about our trivial (the tests used to demonstrate them[/color][/color]
> often[color=green][color=darkred]
> > > use 10,000,000 iterations and our code is doing exactly one per hour,[/color][/color]
> for[color=green][color=darkred]
> > > example). I can't see any wisdom whatsoever in obsessing over such[/color]
> > trivial[color=darkred]
> > > performance gains and sacrificing what may well be hours of future[/color][/color][/color]
work[color=blue]
> on[color=green][color=darkred]
> > > the code.
> > >
> > > As far as the reliability, I think the position of writing code that[/color][/color][/color]
is[color=blue][color=green][color=darkred]
> > > pretty likely to break some day because it performs slightly better is[/color]
> > just[color=darkred]
> > > ludicrous. In this particular case, it was in the context of database
> > > access, which I think will far overshadow any milliseconds saved here[/color][/color][/color]
or[color=blue][color=green][color=darkred]
> > > there by writing theoretically perfect code.
> > >
> > > "J.Marsch" <jeremy@ctcdeve loper.com> wrote in message
> > > news:ekQteEU1DH A.540@tk2msftng p13.phx.gbl...
> > > > For what it's worth I would almost always side with reliability. I[/color][/color]
> hate[color=green][color=darkred]
> > > > fixing code, especially when it's due to a bad decision on my[/color][/color][/color]
behalf.[color=blue]
> I[color=green][color=darkred]
> > > > suppose that if I were in a situation where some code absolutely had[/color][/color]
> to[color=green][color=darkred]
> > > run
> > > > faster (show-stopper), and the modification was the only way to get[/color][/color]
> over[color=green][color=darkred]
> > > the
> > > > line, and the reliability problem was not random, but a maintenance[/color]
> > issue,[color=darkred]
> > > > (only a bug if the table structure changes), and the reliability[/color][/color]
> problem[color=green][color=darkred]
> > > > would not cause more damage than running too slow..
> > > >
> > > > Then maybe I would bring it up in a meeting, just so that my[/color][/color][/color]
coworkers[color=blue][color=green][color=darkred]
> > > could
> > > > talk me out of it.
> > > >
> > > > Regards
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[J.Marsch]

Re: performance vs. readability/maintability

I wholeheartedly agree with your comments about using the right algorithm
and the right data structure. I find that, alot of the time, if some bit of
code isn't performing at expectations, it's because the algorithm or
datastructures are not well matched to the task. In such a situation, you
can often come out with a solution that is _more_ readable, more
maintainable, and more performant!

I side with Einstein. He said that when you find a true answer to a mystery
of the universe, that solution will be simple and elegant.

"Bruno Jouhier [MVP]" <bjouhier@clu b-internet.fr> wrote in message
news:eus8X3U1DH A.3656@TK2MSFTN GP11.phx.gbl...[color=blue]
> I'll follow the trend in the other replies: Readability and[/color]
maintainability[color=blue]
> have highest priority.
>
> Like Mickey, I will only sacrifice readability for performance if I have
> identified the performance bottleneck with a profiler and if there is no
> other way to improve it.
>
> I don't like the idea of introducing low-level optimization hacks "a
> priori". I cannot find one example where this approach really worked and
> brought benefits, but lots of examples where it did not work at all. On[/color]
the[color=blue]
> other hand, spending time on choosing the right data structures (so that
> everything that you will access over and over will be properly indexed in
> your object graphs) and the right algorithms really pays off.
>
> Also, I am very careful in the way I use the language constructs, trying[/color]
to[color=blue]
> make the code as easy to read as possible, and as robust as possible, and
> usually, I can find elegant solutions that don't conflict with the
> performance goal. They may not give the absolute best performance
> (otherwise, I would be writing in C, or even worse, assembly), but they
> usually give a very good balance between clarity and performance.
>
> Bruno.
>
> "Daniel Billingsley" <dbillingsley@N O.durcon.SPAAMM .com> a écrit dans le
> message de news:e5Hr8PT1DH A.2680@TK2MSFTN GP11.phx.gbl...[color=green]
> > In another online group in which I participate, we were discussing a
> > particular piece of code that had a pretty high risk for breaking in the
> > future (because it depended on something not changing that was outside[/color][/color]
the[color=blue][color=green]
> > developer's control) but was slightly more performant. One participant
> > posted:
> >
> > "I tend to take the performance track also, adding readability if the[/color]
> impact[color=green]
> > isn't too great. There is also an odd reality that takes place even in[/color]
> the[color=green]
> > software field however. Not sure I can explain it too well but simply[/color]
> said,[color=green]
> > if you write code to handle the effects of changing the ordinal position[/color]
> of[color=green]
> > a field, some other error will surface anyway."
> >
> > which I found to be ridiculous to the point of being dangerous.
> >
> > I know this is somewhat one of those opinion issues, but I just wondered
> > where everyone fell on the continuum.
> >
> >[/color]
>
>[/color]

[Daniel Billingsley]

Re: performance vs. readability/maintability

Yeah the quote I posted actually makes two points

1) readability vs. performance
2) reliability vs. performance

with the author says he chooses performance in both cases.

My basic position tends to be that in most cases the performance differences
we're talking about our trivial (the tests used to demonstrate them often
use 10,000,000 iterations and our code is doing exactly one per hour, for
example). I can't see any wisdom whatsoever in obsessing over such trivial
performance gains and sacrificing what may well be hours of future work on
the code.

As far as the reliability, I think the position of writing code that is
pretty likely to break some day because it performs slightly better is just
ludicrous. In this particular case, it was in the context of database
access, which I think will far overshadow any milliseconds saved here or
there by writing theoretically perfect code.

"J.Marsch" <jeremy@ctcdeve loper.com> wrote in message
news:ekQteEU1DH A.540@tk2msftng p13.phx.gbl...[color=blue]
> For what it's worth I would almost always side with reliability. I hate
> fixing code, especially when it's due to a bad decision on my behalf. I
> suppose that if I were in a situation where some code absolutely had to[/color]
run[color=blue]
> faster (show-stopper), and the modification was the only way to get over[/color]
the[color=blue]
> line, and the reliability problem was not random, but a maintenance issue,
> (only a bug if the table structure changes), and the reliability problem
> would not cause more damage than running too slow..
>
> Then maybe I would bring it up in a meeting, just so that my coworkers[/color]
could[color=blue]
> talk me out of it.
>
> Regards[/color]