Re: Lua 5.4.2 New assorted suggestions (Part II)

[Kyle Evans <kevans@...>]

On Mon, Nov 23, 2020 at 5:38 AM Ranier Vilela <ranier.vf@gmail.com> wrote:
>
> Em dom., 22 de nov. de 2020 às 18:13, Kyle Evans <kevans@freebsd.org> escreveu:
>> Note that any optimizing compiler worth its salt should be able
>> to identify that it can eliminate the strlen() call at the call sites
>> where it's a literal, providing a less-redundant interface that's
>> "optimal" (not that I think it's necessarily
>> worth it).
>
> I come from the old school, from the days of the MSDOS.
> From my first C course, one of the lessons was: don't leave anything behind.
> Indeed, compilers have evolved a lot.
> But the one who knows the code and the data best is the programmer, not the compiler.
> Then give permission to optimize and the compiler will do a better job.
> It is the same principle of using const, many do not, because the code is less readable.
>

Sure, I'll bow out here, but your approach here could be improved with
an eye towards balancing aesthetics and performance. lua_pushliteral
is better, but the authors have chosen what they have and likely have
a good reason for it given that they've developed both sides of the
API. For instance, proposing an invasive change that sprinkles
sizeof() at each of these invocations is probably not going to be
received well, but a macro gated behind LUA_CORE that doesn't change
the aesthetics of the call sites while still eliminating a call very
well might. If the authors think it's silly and a better choice could
have been made at those callers that you've noted are affected by the
macro, then you've still accomplished something productive.

The other thing to remember is that while you may still have scars
from compilers of the past, trying to outrun compiler optimizations
isn't really all that worthwhile (at least nowadays) over writing
clear and concise code for most applications.

I say all of the above from the perspective of someone that maintains
other projects and regularly reviews submissions from other people.

Thanks,

Kyle Evans