Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #11140 > unrolled thread

please coin a term for a lower order bug

Back to article view | Back to comp.lang.java.programmer

Contents

  please coin a term for a lower order bug Roedy Green <see_website@mindprod.com.invalid> - 2012-01-09 14:02 -0800
    Re: please coin a term for a lower order bug Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-01-09 14:18 -0800
      Re: please coin a term for a lower order bug bugbear <bugbear@trim_papermule.co.uk_trim> - 2012-01-10 09:18 +0000
      Re: please coin a term for a lower order bug George Neuner <gneuner2@comcast.net> - 2012-01-10 11:46 -0500
        Re: please coin a term for a lower order bug David Lamb <dalamb@cs.queensu.ca> - 2012-01-10 16:00 -0500
          Re: please coin a term for a lower order bug markspace <-@.> - 2012-01-10 13:38 -0800
            Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-10 15:14 -0800
        Re: please coin a term for a lower order bug Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-01-10 18:01 -0800
      Re: please coin a term for a lower order bug markspace <-@.> - 2012-01-10 08:52 -0800
        Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 17:52 -0800
          Re: please coin a term for a lower order bug Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-01-10 19:44 -0800
            Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-10 20:35 -0800
          Re: please coin a term for a lower order bug Roedy Green <see_website@mindprod.com.invalid> - 2012-01-11 10:54 -0800
    Re: please coin a term for a lower order bug Ian Pilcher <arequipeno@gmail.com> - 2012-01-09 17:29 -0600
    Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-09 21:26 -0500
      Re: please coin a term for a lower order bug glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-10 02:43 +0000
        Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 07:01 -0800
          Re: please coin a term for a lower order bug Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-11 03:23 -0600
          Re: please coin a term for a lower order bug Wanja Gayk <brixomatic@yahoo.com> - 2012-01-15 13:21 +0100
            Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-15 08:39 -0500
              Re: please coin a term for a lower order bug Patricia Shanahan <pats@acm.org> - 2012-01-15 06:39 -0800
      Re: please coin a term for a lower order bug Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-10 06:45 -0400
        Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-10 07:54 -0500
          Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 07:13 -0800
          Re: please coin a term for a lower order bug Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-10 18:17 -0400
            Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-10 15:23 -0800
          Re: please coin a term for a lower order bug Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-11 03:30 -0600
            Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-11 08:08 -0500
              Re: please coin a term for a lower order bug Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-11 14:38 -0600
                Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-11 15:48 -0800
        Re: please coin a term for a lower order bug Roedy Green <see_website@mindprod.com.invalid> - 2012-01-11 11:01 -0800
          Re: please coin a term for a lower order bug glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-12 01:45 +0000
            Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-11 18:05 -0800
    Re: please coin a term for a lower order bug Jim Janney <jjanney@shell.xmission.com> - 2012-01-10 09:52 -0700
      Re: please coin a term for a lower order bug markspace <-@.> - 2012-01-10 09:51 -0800
        Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 18:08 -0800
          Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-10 19:30 -0800
            Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 22:11 -0800
              Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-11 15:52 -0800
            Re: please coin a term for a lower order bug Jim Janney <jjanney@shell.xmission.com> - 2012-01-11 13:38 -0700
      Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-10 14:05 -0500
    Re: please coin a term for a lower order bug v_borchert@despammed.com (Volker Borchert) - 2012-01-11 20:59 +0000
      Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-11 15:53 -0800
    Re: please coin a term for a lower order bug Fredrik Jonson <fredrik@jonson.org> - 2012-01-12 06:59 +0000
    Re: please coin a term for a lower order bug Wanja Gayk <brixomatic@yahoo.com> - 2012-01-15 12:45 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#11341

On 1/15/2012 5:39 AM, Eric Sosman wrote:
> On 1/15/2012 7:21 AM, Wanja Gayk wrote:
>> In article<jehjrs$3ba$1@news.albasani.net>, noone@lewscanon.com says...
>>
>>> A bug is a bug.
>>
>> If something runs correctly, but slower than necessary, but still
>> acceptable, how can it be a bug?
>
> As a preliminary, let's note that the phrase "but still
> acceptable" was not part of the bug description until you added
> it. With that in mind, on to the story:
>
> In 1981 I was peripherally involved with a system that did
> interactive searches of a newspaper's content. (If that doesn't
> sound remarkable, take note of the era: Before Google, before Yahoo,
> before Altavista, before the Web itself, before the first IBM PC.)
> One gang of PDP-11 computers handled the searching, and another gang
> digested the newspaper's daily data flow and updated the indices.
>
> At one major metropolitan newspaper, the system was running
> smoothly and doing its job pretty much as intended. Sure, there
> were hiccups, but they did not seriously inconvenience the system's
> users or operators. Yet despite the mostly correct functioning, the
> installation was an abject failure. Why?
>
> Because feeding one day's worth of copy through the indexer took
> about twenty-eight hours.
>

I would say that was a definite performance bug - one of the
requirements was to process one day's worth of copy in less than 24 hours.

Here's another practical example, at little bit further in the non-bug
direction. Many years ago, I was working for a computer manufacturer
whose customers included an oil exploration consulting firm. Their major
resource was people who could interpret seismometer traces.

There were several different transformations on the traces, so one work
flow had an expert study a trace, choose the next transformation, give
it to the computer, then go work on something else for the next few
hours or even days. Even if the original task was the expert's highest
priority, nothing useful could be done on it. The sooner the transformed
data came back, the sooner the expert would have the option of returning
to the original task.

In that sort of situation there is a minimum acceptable speed, but
faster is better.

Patricia

[toc] | [prev] | [next] | [standalone]

#11162

On 12-01-09 10:26 PM, Eric Sosman wrote:
> On 1/9/2012 5:02 PM, Roedy Green wrote:
>> What would you call a flaw in a program that had no effect on the
>> results, but needlessly made the program slower or confusing?
> 
>     Call them "bugs."  Sub-classification as "venial bugs" and
> "mortal bugs" just reveals the classifier's lack of imagination.
> 
True. But until this slow or confusing behaviour violated a business or
technical requirement it's no bug at all. After all, what is "slow"? And
"confusing" to who?

AHS
-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

[toc] | [prev] | [next] | [standalone]

#11165

On 1/10/2012 5:45 AM, Arved Sandstrom wrote:
> On 12-01-09 10:26 PM, Eric Sosman wrote:
>> On 1/9/2012 5:02 PM, Roedy Green wrote:
>>> What would you call a flaw in a program that had no effect on the
>>> results, but needlessly made the program slower or confusing?
>>
>>      Call them "bugs."  Sub-classification as "venial bugs" and
>> "mortal bugs" just reveals the classifier's lack of imagination.
>>
> True. But until this slow or confusing behaviour violated a business or
> technical requirement it's no bug at all. After all, what is "slow"? And
> "confusing" to who?

     The fact that the program is being called slow and confusing
demonstrates that it is neither "fast enough" nor "clear enough."
If the program were satisfactory, nobody would be complaining --
but they are complaining, ergo the program does not meet expectations.

     Note that some bugs are addressed by means other than changing
the code.  We might, for example, relabel the program as "Only for
use on big honkin' screamerboxen" or "Not for use by addlepated
nitwits."  That is, sometimes the failure to fulfill expectations
is remedied by better control of the expectations.  Nonetheless, it's
a bug until and unless *something* is done.

     (The software purveyors' pusillanimous retreat behing "Not
warrantied for any particular use whatsoever" is beneath contempt.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#11175

Eric Sosman wrote:
> (The software purveyors' pusillanimous retreat behing "Not
> warrantied for any particular use whatsoever" is beneath contempt.)

There's a difference between a claim and a warranty.  The phrase "not 
warranteed for any purpose" doesn't mean that the product won't work or that 
they don't think it will, it means you won't get any money if it fails.  I 
don't think that's beneath contempt; on the contrary I think it's entirely 
worthy of contempt.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11192

On 12-01-10 08:54 AM, Eric Sosman wrote:
> On 1/10/2012 5:45 AM, Arved Sandstrom wrote:
>> On 12-01-09 10:26 PM, Eric Sosman wrote:
>>> On 1/9/2012 5:02 PM, Roedy Green wrote:
>>>> What would you call a flaw in a program that had no effect on the
>>>> results, but needlessly made the program slower or confusing?
>>>
>>>      Call them "bugs."  Sub-classification as "venial bugs" and
>>> "mortal bugs" just reveals the classifier's lack of imagination.
>>>
>> True. But until this slow or confusing behaviour violated a business or
>> technical requirement it's no bug at all. After all, what is "slow"? And
>> "confusing" to who?
> 
>     The fact that the program is being called slow and confusing
> demonstrates that it is neither "fast enough" nor "clear enough."
> If the program were satisfactory, nobody would be complaining --
> but they are complaining, ergo the program does not meet expectations.

Who's "they"? I run into this situation often enough, particularly with
respect to application performance. 9 times out of 10 the people who
complain about slowness haven't measured the current performance,
haven't any baseline data for the performance of any previous versions,
and there are zero business/technical requirements that define target
performance. In the absence of all that the complaint is entirely
subjective, and there is no defect.

I'd be surprised if _you_ set out to "improve" performance without a
specified, agreed target at a minimum.

As for "confusing", if it's a trained user of the program who's
complaining, for some common-sense value of "trained", then maybe I'll
take the complaint seriously. "Trained" to me means that the program
_documentation_ is adequate or better, that the user is familiar with
it, and that if proper operation of the program also requires other
knowledge (like that of business processes, or of some subject, or of
some professional occupation) that the user possesses that knowledge.

I've seen way too many people complain that something is "confusing"
about an application where they lack any of these prerequisites. I'm
sorry, but they can go suck eggs until they do their bit first.

In a more active way you take care of "confusing" by getting user
interfaces (command line, graphical etc) and use cases and storylines
out in front of the user community as soon as possible. This should
happen in requirements at the latest. That's where the prospective users
have their opportunity to eliminate the "confusing" bits.

>     Note that some bugs are addressed by means other than changing
> the code.  We might, for example, relabel the program as "Only for
> use on big honkin' screamerboxen" or "Not for use by addlepated
> nitwits."  That is, sometimes the failure to fulfill expectations
> is remedied by better control of the expectations.  Nonetheless, it's
> a bug until and unless *something* is done.

I'll agree that it could be viewed as a requirements defect, sure. OTOH,
if the business signed off on the requirements documents, it's really a
change request.

>     (The software purveyors' pusillanimous retreat behing "Not
> warrantied for any particular use whatsoever" is beneath contempt.)
> 
I agree. But I don't think we're talking about that here. I know I'm not.

AHS
-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

[toc] | [prev] | [next] | [standalone]

#11196

On Tue, 10 Jan 2012 18:17:48 -0400, Arved Sandstrom
<asandstrom3minus1@eastlink.ca> wrote:

>On 12-01-10 08:54 AM, Eric Sosman wrote:
>> On 1/10/2012 5:45 AM, Arved Sandstrom wrote:
>>> On 12-01-09 10:26 PM, Eric Sosman wrote:
>>>> On 1/9/2012 5:02 PM, Roedy Green wrote:
>>>>> What would you call a flaw in a program that had no effect on the
>>>>> results, but needlessly made the program slower or confusing?
>>>>
>>>>      Call them "bugs."  Sub-classification as "venial bugs" and
>>>> "mortal bugs" just reveals the classifier's lack of imagination.
>>>>
>>> True. But until this slow or confusing behaviour violated a business or
>>> technical requirement it's no bug at all. After all, what is "slow"? And
>>> "confusing" to who?
>> 
>>     The fact that the program is being called slow and confusing
>> demonstrates that it is neither "fast enough" nor "clear enough."
>> If the program were satisfactory, nobody would be complaining --
>> but they are complaining, ergo the program does not meet expectations.
>
>Who's "they"? I run into this situation often enough, particularly with

     You know, them.  <BEG>

>respect to application performance. 9 times out of 10 the people who
>complain about slowness haven't measured the current performance,
>haven't any baseline data for the performance of any previous versions,
>and there are zero business/technical requirements that define target
>performance. In the absence of all that the complaint is entirely

     Agreed to here.

>subjective, and there is no defect.

     Not quite.  It may be real but unproven.  You and I want proven.

     And for that matter, it might well seem slower, but not be any
slower.  I have had this happen to me personally.  It is embarassing
to me when I measure to prove my point, and the two numbers are the
same or nearly so.  Real numbers, please.

>I'd be surprised if _you_ set out to "improve" performance without a
>specified, agreed target at a minimum.

     Quite.

>As for "confusing", if it's a trained user of the program who's
>complaining, for some common-sense value of "trained", then maybe I'll
>take the complaint seriously. "Trained" to me means that the program
>_documentation_ is adequate or better, that the user is familiar with
>it, and that if proper operation of the program also requires other
>knowledge (like that of business processes, or of some subject, or of
>some professional occupation) that the user possesses that knowledge.

     And that the user is making a reasonable effort to use the
program.  "It doesn't work!" does not count for much with me when I
can make it work, or when others can.

>I've seen way too many people complain that something is "confusing"
>about an application where they lack any of these prerequisites. I'm
>sorry, but they can go suck eggs until they do their bit first.

     OK, I just said that, too.

>In a more active way you take care of "confusing" by getting user
>interfaces (command line, graphical etc) and use cases and storylines
>out in front of the user community as soon as possible. This should
>happen in requirements at the latest. That's where the prospective users
>have their opportunity to eliminate the "confusing" bits.

     I would also like a solution from the user.  What would solve the
confusion problem?  The answer need not necessarily be detailed, but
"I don't know.  Just make it better." will not do.

>>     Note that some bugs are addressed by means other than changing
>> the code.  We might, for example, relabel the program as "Only for
>> use on big honkin' screamerboxen" or "Not for use by addlepated
>> nitwits."  That is, sometimes the failure to fulfill expectations
>> is remedied by better control of the expectations.  Nonetheless, it's
>> a bug until and unless *something* is done.

     There was an example from decades ago where having some entry
forms which specified the units of measure did the trick.

>I'll agree that it could be viewed as a requirements defect, sure. OTOH,
>if the business signed off on the requirements documents, it's really a
>change request.

     Yes.

>>     (The software purveyors' pusillanimous retreat behing "Not
>> warrantied for any particular use whatsoever" is beneath contempt.)
>> 
>I agree. But I don't think we're talking about that here. I know I'm not.

     I get leery of warranting something considering how vague the
"specs" can be in the first place.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#11221

Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
> 
>     The fact that the program is being called slow and confusing
> demonstrates that it is neither "fast enough" nor "clear enough."

Or it demonstrates that the commentator doesn't understand the scope
of the problem the program deals with.

> If the program were satisfactory, nobody would be complaining --
> but they are complaining, ergo the program does not meet expectations.

Then again, that may be a problem with the expectations, not the
program. (That's not usually the case, mind. Usually it _is_ the
program that's to blame.)

Some people just plain like to complain.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#11224

On 1/11/2012 4:30 AM, Leif Roar Moldskred wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>>
>>      The fact that the program is being called slow and confusing
>> demonstrates that it is neither "fast enough" nor "clear enough."
>
> Or it demonstrates that the commentator doesn't understand the scope
> of the problem the program deals with.

     They've been snipped from your response, but I think my
remarks about controlling expectations cover this case.  Look
for the paragraph beginning "Note that some bugs are addressed
by means other than changing the code."

     Observe that this approach to managing context is not unique
to software.  It's a "bug" that some powerful medications come
in the form of colorful pills that small children may mistake
for candy.  The response is not to alter the medicine's potency,
but to inform adults that the product is NOT to be operated by
children.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#11242

Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
>
>     They've been snipped from your response, but I think my
> remarks about controlling expectations cover this case.

I'm just saying that there are people whose expectations are beyond
control. 

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#11246

On Wed, 11 Jan 2012 14:38:11 -0600, Leif Roar Moldskred
<leifm@dimnakorr.com> wrote:

>Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
>>
>>     They've been snipped from your response, but I think my
>> remarks about controlling expectations cover this case.
>
>I'm just saying that there are people whose expectations are beyond
>control.

     BANG!

     Any others?

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#11234

On Tue, 10 Jan 2012 06:45:08 -0400, Arved Sandstrom
<asandstrom3minus1@eastlink.ca> wrote, quoted or indirectly quoted
someone who said :

> After all, what is "slow"?

there are two different kinds of slow.

1. unoptimised.  You don't do this until you prove a need for it, and
you do it at the end.

2. stupidly slow. e.g.  calling a method twice in succession for no
reason, using a bubble sort when a perfectly decent sort is built n
squared algorithms that can't possibly scale to what will be required.

There is a snob attitude to DELIBERATELY waste resources, picking the
inefficient technique even when the programmer knows a better one that
is no more difficult.  This is how we manage to make computers with
3000 times the computer power less responsive that XTs.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One of the most useful comments you can put in a program is 
"If you change this, remember to change ?XXX? too".
 

[toc] | [prev] | [next] | [standalone]

#11250

Roedy Green <see_website@mindprod.com.invalid> wrote:

(snip on ways to make programs slow)

> 2. stupidly slow. e.g.  calling a method twice in succession for no
> reason, using a bubble sort when a perfectly decent sort is built n
> squared algorithms that can't possibly scale to what will be required.

Some are not so obvious. 
Building long strings with strcat() in C is O(n**2). 
I once had to find and fix this in a program that put together
megabytes one line at a time.

> There is a snob attitude to DELIBERATELY waste resources, picking the
> inefficient technique even when the programmer knows a better one that
> is no more difficult.  This is how we manage to make computers with
> 3000 times the computer power less responsive that XTs.

My favorite one to complain about is programs that read in a whole
data set to process, when it could be done just as well one record,
or small group of records, at a time. 

-- glen

[toc] | [prev] | [next] | [standalone]

#11251

On Thu, 12 Jan 2012 01:45:34 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

[snip]

>My favorite one to complain about is programs that read in a whole
>data set to process, when it could be done just as well one record,
>or small group of records, at a time. 

     Or where rows in a database are processed record-style (all being
read to the client and then written back) when the whole shebang could
be dealt with in an SQL statement.

     Similarly, when local recordsets are run through for matching
rows instead of selecting with a condition in the first place.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#11182

Roedy Green <see_website@mindprod.com.invalid> writes:

> What would you call a flaw in a program that had no effect on the
> results, but needlessly made the program slower or confusing?

What about one that makes it more confusing and needlessly faster?

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#11184

On 1/10/2012 8:52 AM, Jim Janney wrote:
> Roedy Green<see_website@mindprod.com.invalid>  writes:
>
>> What would you call a flaw in a program that had no effect on the
>> results, but needlessly made the program slower or confusing?
>
> What about one that makes it more confusing and needlessly faster?
>


"Needlessly faster" as in the customer didn't need a speed improvement 
in that feature?  I'd say that's Gold Plating.

<http://en.wikipedia.org/wiki/Gold_plating_%28software_engineering%29>

[toc] | [prev] | [next] | [standalone]

#11205

markspace wrote:
> Jim Janney wrote:
>> Roedy Green writes:
>>> What would you call a flaw in a program that had no effect on the
>>> results, but needlessly made the program slower or confusing?

Slower _is_ an effect on results.

>> What about one that makes it more confusing and needlessly faster?
>
> "Needlessly faster" as in the customer didn't need a speed improvement in that
> feature? I'd say that's Gold Plating.
>
> <http://en.wikipedia.org/wiki/Gold_plating_%28software_engineering%29>

Only if it is superfluous code.  Some very relevant and proper code makes 
things faster, such as use of a good algorithm.  It isn't necessarily gold 
plating.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11211

On Tue, 10 Jan 2012 18:08:15 -0800, Lew <noone@lewscanon.com> wrote:

>markspace wrote:
>> Jim Janney wrote:
>>> Roedy Green writes:
>>>> What would you call a flaw in a program that had no effect on the
>>>> results, but needlessly made the program slower or confusing?
>
>Slower _is_ an effect on results.
>
>>> What about one that makes it more confusing and needlessly faster?
>>
>> "Needlessly faster" as in the customer didn't need a speed improvement in that
>> feature? I'd say that's Gold Plating.
>>
>> <http://en.wikipedia.org/wiki/Gold_plating_%28software_engineering%29>
>
>Only if it is superfluous code.  Some very relevant and proper code makes 
>things faster, such as use of a good algorithm.  It isn't necessarily gold 
>plating.

     If the speed was not required and the change was made to increase
the speed, then it is goldplating.

     I often write code that is not optimal for speed, because it is
easier to maintain.  If the code had to be faster, I would modify it.
If it is fast enough, why bother?  There are enough other things to
do.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#11216

Gene Wirchenko wrote:
> Lew wrote:
>> markspace wrote:
>>> Jim Janney wrote:
>>>> Roedy Green writes:
>>>>> What would you call a flaw in a program that had no effect on the
>>>>> results, but needlessly made the program slower or confusing?
>>
>> Slower _is_ an effect on results.
>>
>>>> What about one that makes it more confusing and needlessly faster?
>>>
>>> "Needlessly faster" as in the customer didn't need a speed improvement in that
>>> feature? I'd say that's Gold Plating.
>>>
>>> <http://en.wikipedia.org/wiki/Gold_plating_%28software_engineering%29>
>>
>> Only if it is superfluous code.  Some very relevant and proper code makes
>> things faster, such as use of a good algorithm.  It isn't necessarily gold
>> plating.
>
>       If the speed was not required and the change was made to increase
> the speed, then it is goldplating.

That's a good way to tell the difference.  We weren't talking about changes, 
we were talking about flaws, but regardless.  No one posited that the change 
was not required, nor that it was made for the purpose of increasing speed. 
It is quite possible to make a change that is required or has a functional 
purpose that also, and inevitably, makes the program faster.  Then it is not 
goldplating.

Applying your litmus test can tell the difference.

>       I often write code that is not optimal for speed, because it is
> easier to maintain.  If the code had to be faster, I would modify it.
> If it is fast enough, why bother?  There are enough other things to
> do.

Quite so.  But speed is not something to avoid, either, not if it is a byblow 
of better algorithm and smarter coding.  It is as dangerous a religion to shun 
speed in the name of not prematurely optimizing as it is to chase it prematurely.

There is also more than one metric of speed.  When you do optimize for speed, 
make sure it's the right kind.  I've seen performance choke on something sped 
up for the single-thread case when the target environment was heavily 
multithreaded.  Lock contention cascades non-linearly after a threshold. 
Individual service response time is not the same as system throughput.

Strangely (not), such premature optimizations were also horrid code with no 
functional purpose.  To call them gold-plating does them too much credit. 
More like poop plating.  A correct algorithm would have omitted the premature 
gold-, er, poop-plated monstrosity.  And been both easier to maintain and 
faster.  And used less memory.

Gene, I agree with your points.  But let us not swing too far the other way 
and eschew non-premature early optimization.  Correct logic more frequently 
than not creates maintainable, fast and memory-efficient code as an emergent 
consequence.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11247

On Tue, 10 Jan 2012 22:11:44 -0800, Lew <noone@lewscanon.com> wrote:

[snip]

>Gene, I agree with your points.  But let us not swing too far the other way 
>and eschew non-premature early optimization.  Correct logic more frequently 
>than not creates maintainable, fast and memory-efficient code as an emergent 
>consequence.

     I do not think that we are disagreeing at all.

     Often, the reasonable effort is <adjective> enough.  If you
really need the extra and are willing to pay for the resulting hair in
the code, then it gets messy.

     If nothing else, youhave a pre-hair version in case the
conditions requiring the hair go away.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#11243

Gene Wirchenko <genew@ocis.net> writes:

> On Tue, 10 Jan 2012 18:08:15 -0800, Lew <noone@lewscanon.com> wrote:
>
>>markspace wrote:
>>> Jim Janney wrote:
>>>> Roedy Green writes:
>>>>> What would you call a flaw in a program that had no effect on the
>>>>> results, but needlessly made the program slower or confusing?
>>
>>Slower _is_ an effect on results.
>>
>>>> What about one that makes it more confusing and needlessly faster?
>>>
>>> "Needlessly faster" as in the customer didn't need a speed improvement in that
>>> feature? I'd say that's Gold Plating.
>>>
>>> <http://en.wikipedia.org/wiki/Gold_plating_%28software_engineering%29>
>>
>>Only if it is superfluous code.  Some very relevant and proper code makes 
>>things faster, such as use of a good algorithm.  It isn't necessarily gold 
>>plating.
>
>      If the speed was not required and the change was made to increase
> the speed, then it is goldplating.
>
>      I often write code that is not optimal for speed, because it is
> easier to maintain.  If the code had to be faster, I would modify it.
> If it is fast enough, why bother?  There are enough other things to
> do.

I focus on making the code clear before anything else.  Then I make sure
it's correct -- this is much easier when it's already clear.  Then, if
it turns out to be necessary, I worry about making it fast -- again,
this is much easier if you have clear correct code to start from.

First rule of performance tuning: the problem is never where you thought
it was going to be.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web