Re: [PATCH] Redudant initilization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Redudant initilization
Date: 2020-09-05 17:29:08
Message-ID: 1220069.1599326948@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> writes:
> Attached is a patch I made in March/2020, but due to problems,
> it was sent but did not make the list.
> Would you mind taking a look?

I applied some of this, but other parts had been overtaken by
events, and there were other changes that I didn't agree with.

A general comment on the sort of "dead store" that I don't think
we should remove is where a function is trying to maintain an
internal invariant, such as "this pointer points past the last
data written to a buffer" or "these two variables are in sync".
If the update happens to be the last one in the function, the
compiler may be able to see that the store is dead ... but IMO
it should just optimize such a store away and not get in the
programmer's face about it. If we manually remove the dead
store then what we've done is broken the invariant, and we'll
pay for that in future bugs and maintenance costs. Somebody
may someday want to add more code after the step in question,
and if they fail to undo the manual optimization then they've
got a bug. Besides which, it's confusing when a function
does something the same way N-1 times and then differently the
N'th time.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2020-09-05 17:44:20 Re: [PATCH] Redudant initilization
Previous Message Juan José Santamaría Flecha 2020-09-05 17:22:23 Re: A micro-optimisation for walkdir()