Re: removing useless if-before-free tests

[Bruno Haible]

Hi Jim,

> >> How about if I remove them all, and then restore-with-justification
> >> the ones for which you think there is a significant performance gain?
>
> You have misread.  I offered to make both changes.

Sorry about it. I indeed misread it, and felt to be put under pressure by
your proposal. I now realize that it was not your intent to put me under
pressure.

> Personally, I would not add an extra test like that unless I'd
> profiled the code in question and found a significant improvement.
> And if I'd taken the time to profile and add the test, I would have
> felt obliged to add a comment justifying code what otherwise might seem
> redundant.

This is a perfectly good, professional way of doing. I don't criticize it
when you apply it to code that you maintain.

Regarding code that I wrote and/or maintain, however, I proceed differently,
because of some past experience profiling CLN and other programs.

> I saw this as a simple, mechanical, obviously-correct, and
> non-controversial change.  I wanted to make the global change
> efficiently (spending little of my time), and didn't anticipate
> any objection.  That was my mind-set when I started this thread.

Yes, but sorry to deceive you: the change is controversial.

But I don't want to convince you, nor do I think you can convince me.
On a shared project, we need to agree on coding style, ChangeLog format,
commit rules, and principles of quality. I don't think we need to agree on
which micro-optimization is generally worth it, or only in particular cases,
or never. These are calls of judgement, and just as I respect your judgement
regarding code that you know, please respect my judgement that is based
on profiling CLN, CLISP and others, regarding code that I maintain.

>> the majority appears to be in the case where NULL
>> is frequently used, i.e. where the 'if' should be kept for performance.
>
> I'm surprised that you would come to such a conclusion.
> I've been taught that "preoptimization is the root of all evil" (Knuth).
> If you've already made some performance measurements to support that
> claim, please let us know.

One such performance measurement was on a program on which the data
structures, algorithms and code were already fully optimized. At this
stage, no algorithm change could gain more performance. But by adding
'inline' at selected places, I gained 5% or something like that. This
taught me that function call overhead is not negligible and should
be considered. (Of course, choice of data structures, algorithm and
size of memory representation have a bigger effect on performance,
but once you've done that, function call overhead is something to care
about.)

Another experience that I made on another time, is that NULLs, empty lists,
loops which are exited before the first round, etc. are more frequent than
one might think.

But again, you don't need to believe this. Please only allow code maintained
by me to be written according to these beliefs.

Bruno