On Sat, Nov 21, 2020 at 2:44 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
>
> Em sáb., 21 de nov. de 2020 às 16:05, Kyle Evans <kevans@freebsd.org> escreveu:
>>
>> On Sat, Nov 21, 2020 at 11:44 AM Ranier Vilela <ranier.vf@gmail.com> wrote:
>> >
>> > Em sáb., 21 de nov. de 2020 às 14:38, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> escreveu:
>> >>
>> >> > /* avoid strlen call or inline */
>> >> > lua_pushlstring(L, "cannot close standard file", sizeof("cannot close standard file") - 1);
>> >>
>> >> I suggest you use lua_pushliteral for string literals; it's good documentation.
>> >>
>> >> lua_pushliteral is currently defined as lua_pushstring but in Lua 5.2
>> >> and previous versions it was defined as
>> >> #define lua_pushliteral(L, s) lua_pushlstring(L, "" s,
>> >> (sizeof(s)/sizeof(char))-1)
>> >> See https://www.lua.org/source/5.2/lua.h.html#lua_pushliteral
>> >>
>> >> You may want to redefine lua_pushliteral back to this if you are
>> >> worried about strlen on literals.
>> >
>> > It would be better for everyone in the Lua 5.4 git?
>>
>> Please stop, unless you're going to actually benchmark or analyze this
>> stuff correctly. One brief look at the implementation of luaS_new vs.
>> luaS_newlstr and I cannot fathom why you would bother trying to
>> introduce performance regressions like this. I haven't looked at it
>> all that much, but I will eat my hat if you can prove that the
>> literals you're trying to convert to lua_pushlstring aren't in the
>> cache for over 95% of these invocations in the real world.
>
> I think you are right here, but for the wrong reason.
> In luaT_init, the cache will most likely be empty.
> But when changing LuaS_new for luaS_newlstr, the cache initialization is lost, so it really isn't worth it.
> Perhaps, if luaS_newlen (lua_State * L, const char * str, size_t len), was created, let it go.
> So I take that example back.
Ok, that's a good start. Can you explain why, for the rest of these,
you're advocating for luaL_addlstring vs. just providing an internal
luaL_addstring macro in some header that does exactly what
luaL_addstring does?
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.
regards,
