lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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.