On Sat, Nov 21, 2020 at 2:44 PM Ranier Vilela <firstname.lastname@example.org> wrote:
> Em sáb., 21 de nov. de 2020 às 16:05, Kyle Evans <email@example.com> escreveu:
>> On Sat, Nov 21, 2020 at 11:44 AM Ranier Vilela <firstname.lastname@example.org> wrote:
>> > Em sáb., 21 de nov. de 2020 às 14:38, Luiz Henrique de Figueiredo <email@example.com> 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
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
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.