Lua 5.4.2 New assorted suggestions (Part II)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Lua 5.4.2 New assorted suggestions (Part II)

Ranier Vilela-2
Hi,

More new assorted suggestions for the Lua.

10. Avoid calling strlen at lua_addstring, when adding a constant literal string.

diff --git a/lauxlib.c b/lauxlib.c
index 73504389..e28872cd 100644
--- a/lauxlib.c
+++ b/lauxlib.c
@@ -139,7 +139,7 @@ LUALIB_API void luaL_traceback (lua_State *L, lua_State *L1,
     luaL_addstring(&b, msg);
     luaL_addchar(&b, '\n');
   }
-  luaL_addstring(&b, "stack traceback:");
+  luaL_addsltring(&b, "stack traceback:", sizeof("stack traceback:") - 1);
   while (lua_getstack(L1, level++, &ar)) {
     if (limit2show-- == 0) {  /* too many levels? */
       int n = last - level - LEVELS2 + 1;  /* number of levels to skip */
@@ -157,7 +157,7 @@ LUALIB_API void luaL_traceback (lua_State *L, lua_State *L1,
       pushfuncname(L, &ar);
       luaL_addvalue(&b);
       if (ar.istailcall)
-        luaL_addstring(&b, "\n\t(...tail calls...)");
+        luaL_addlstring(&b, "\n\t(...tail calls...)", sizeof("\n\t(...tail calls...)") -1);
     }
   }
   luaL_pushresult(&b);

11. Avoid calling strlen at lua_addstring, when adding a constant literal string.

diff --git a/loadlib.c b/loadlib.c
index c0ec9a13..627cece5 100644
--- a/loadlib.c
+++ b/loadlib.c
@@ -469,9 +469,9 @@ static const char *getnextfilename (char **path, char *end) {
 static void pusherrornotfound (lua_State *L, const char *path) {
   luaL_Buffer b;
   luaL_buffinit(L, &b);
-  luaL_addstring(&b, "no file '");
+  luaL_addlstring(&b, "no file '", sizeof("no file '") - 1);
   luaL_addgsub(&b, path, LUA_PATH_SEP, "'\n\tno file '");
-  luaL_addstring(&b, "'");
+  luaL_addchar(&b, '\'');
   luaL_pushresult(&b);
 }

12. Avoid calling strlen at lua_addstring, when adding a constant literal string.

@@ -628,7 +628,7 @@ static void findloader (lua_State *L, const char *name) {
   luaL_buffinit(L, &msg);
   /*  iterate over available searchers to find a loader */
   for (i = 1; ; i++) {
-    luaL_addstring(&msg, "\n\t");  /* error-message prefix */
+    luaL_addlstring(&msg, "\n\t", sizeof("\n\t") - 1);  /* error-message prefix */
     if (lua_rawgeti(L, 3, i) == LUA_TNIL) {  /* no more searchers? */
       lua_pop(L, 1);  /* remove nil */
       luaL_buffsub(&msg, 2);  /* remove prefix */

13. Avoid calling strlen at lua_pushstring, when pushing a constant literal string.

diff --git a/ltablib.c b/ltablib.c
index d344a47e..d56f5394 100644
--- a/ltablib.c
+++ b/ltablib.c
@@ -33,8 +33,8 @@
 #define aux_getn(L,n,w) (checktab(L, n, (w) | TAB_L), luaL_len(L, n))
 
 
-static int checkfield (lua_State *L, const char *key, int n) {
-  lua_pushstring(L, key);
+static int checkfield (lua_State *L, const char *key, size_t len, int n) {
+  lua_pushlstring(L, key, len);
   return (lua_rawget(L, -n) != LUA_TNIL);
 }
 
@@ -47,9 +47,9 @@ static void checktab (lua_State *L, int arg, int what) {
   if (lua_type(L, arg) != LUA_TTABLE) {  /* is it not a table? */
     int n = 1;  /* number of elements to pop */
     if (lua_getmetatable(L, arg) &&  /* must have metatable */
-        (!(what & TAB_R) || checkfield(L, "__index", ++n)) &&
-        (!(what & TAB_W) || checkfield(L, "__newindex", ++n)) &&
-        (!(what & TAB_L) || checkfield(L, "__len", ++n))) {
+        (!(what & TAB_R) || checkfield(L, "__index", sizeof("__index") - 1, ++n)) &&
+        (!(what & TAB_W) || checkfield(L, "__newindex", sizeof("__newindex") - 1, ++n)) &&
+        (!(what & TAB_L) || checkfield(L, "__len", sizeof("__len") - 1, ++n))) {
       lua_pop(L, n);  /* pop metatable and tested metamethods */
     }
     else

regards,
Ranier Vilela

all2.patch (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Ranier Vilela-2
Em seg., 16 de nov. de 2020 às 08:37, Ranier Vilela <[hidden email]> escreveu:
Hi,

More new assorted suggestions for the Lua.

10. Avoid calling strlen at lua_addstring, when adding a constant literal string.

diff --git a/lauxlib.c b/lauxlib.c
index 73504389..e28872cd 100644
--- a/lauxlib.c
+++ b/lauxlib.c
@@ -139,7 +139,7 @@ LUALIB_API void luaL_traceback (lua_State *L, lua_State *L1,
     luaL_addstring(&b, msg);
     luaL_addchar(&b, '\n');
   }
-  luaL_addstring(&b, "stack traceback:");
+  luaL_addlstring(&b, "stack traceback:", sizeof("stack traceback:") - 1);
Typo.

14.  Avoid calling strlen at lua_addstring, when the size of is known.

diff --git a/lstrlib.c b/lstrlib.c
index 940a14ca..8ab967d2 100644
--- a/lstrlib.c
+++ b/lstrlib.c
@@ -1106,12 +1106,13 @@ static void addquoted (luaL_Buffer *b, const char *s, size_t len) {
       luaL_addchar(b, *s);
     }
     else if (iscntrl(uchar(*s))) {
-      char buff[10];
+      char buff[12];
+  size_t l;
       if (!isdigit(uchar(*(s+1))))
-        l_sprintf(buff, sizeof(buff), "\\%d", (int)uchar(*s));
+        l = l_sprintf(buff, sizeof(buff), "\\%d", (int)uchar(*s));
       else
-        l_sprintf(buff, sizeof(buff), "\\%03d", (int)uchar(*s));
-      luaL_addstring(b, buff);
+        l = l_sprintf(buff, sizeof(buff), "\\%03d", (int)uchar(*s));
+      luaL_addlstring(b, buff, l);
     }
     else
       luaL_addchar(b, *s);

regards,
Ranier Vilela

all2.patch (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Dibyendu Majumdar
In reply to this post by Ranier Vilela-2
Hi,

Perhaps you are new here - so you may not be aware.
Lua team do not take patches.

Also the Lua code is extremely well thought out and has over 20 years
of effort behind it. There are still bugs and if you find a bug, you
should report it. But it is presumptuous to suggest code changes
without a proper understanding of it.

Regards
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Ranier Vilela-2
Em seg., 16 de nov. de 2020 às 09:06, Dibyendu Majumdar <[hidden email]> escreveu:
Hi,

Perhaps you are new here - so you may not be aware.
Lua team do not take patches.
Oh yes, I heard that.
But patches are the usual way to contribute and make it very clear what is being suggested, which can avoid a dozen messages.
 

Also the Lua code is extremely well thought out and has over 20 years
of effort behind it. There are still bugs and if you find a bug, you
should report it. But it is presumptuous to suggest code changes
without a proper understanding of it.
Really.
I could sit, waiting for improvements too.
But I want Lua to be faster and safer.
I'm trying to do that.
IMHO, you could do the same, don't you think.

regards,
Ranier Vilela
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Dibyendu Majumdar
On Mon, 16 Nov 2020 at 12:29, Ranier Vilela <[hidden email]> wrote:

>> Also the Lua code is extremely well thought out and has over 20 years
>> of effort behind it. There are still bugs and if you find a bug, you
>> should report it. But it is presumptuous to suggest code changes
>> without a proper understanding of it.
>
> Really.
> I could sit, waiting for improvements too.
> But I want Lua to be faster and safer.
> I'm trying to do that.

Problem is none of your suggested changes will make it better or
faster because you seem to lack understanding of what the issues are.


Regards
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Ranier Vilela-2
Em seg., 16 de nov. de 2020 às 09:54, Dibyendu Majumdar <[hidden email]> escreveu:
On Mon, 16 Nov 2020 at 12:29, Ranier Vilela <[hidden email]> wrote:

>> Also the Lua code is extremely well thought out and has over 20 years
>> of effort behind it. There are still bugs and if you find a bug, you
>> should report it. But it is presumptuous to suggest code changes
>> without a proper understanding of it.
>
> Really.
> I could sit, waiting for improvements too.
> But I want Lua to be faster and safer.
> I'm trying to do that.

Problem is none of your suggested changes will make it better or
faster.
IMO, that is your opinion. Maybe Lua Team has another opinion.
 
because you seem to lack understanding of what the issues are.
Maybe. But I am learning on the way.
Usually I write optimized code, it has worked for me.

regards,
Ranier Vilela
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Chris Smith

> On 16 Nov 2020, at 13:03, Ranier Vilela <[hidden email]> wrote:
>
> Usually I write optimized code, it has worked for me.

You know the first three rules of optimisation, right?  They are, in order:

1. Measure
2. Measure
3. Measure

Show that there is a problem.  Show that there is a measurable benefit to fixing it.  Show that your ‘fix’ works and backs up your claims.

Chris

Chris Smith <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Dibyendu Majumdar
In reply to this post by Ranier Vilela-2
On Mon, 16 Nov 2020 at 13:04, Ranier Vilela <[hidden email]> wrote:
>> because you seem to lack understanding of what the issues are.
>
> Maybe. But I am learning on the way.

Okay - be patient. Learn and test it thoroughly and only when you can
demonstrate a real bug or perf improvement (by a factor greater than
10%) then report back.
Make sure you have run the Lua tests with full checking on before you
suggest a change.
Perf testing is very tricky and hard to prove by the way.

My advice is - Lua is well suited for forking - so go head and do
that, and prove your changes are worth it.

Regards
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Petite Abeille
In reply to this post by Ranier Vilela-2


> On Nov 16, 2020, at 14:03, Ranier Vilela <[hidden email]> wrote:
>
> IMO, that is your opinion.

The proof is in the pudding. As mentioned by others, test your suggestions for correctness, and speed. No one else is going to do that for you.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Luiz Henrique de Figueiredo
In reply to this post by Chris Smith
> You know the first three rules of optimisation, right?  They are, in order:
>
> 1. Measure
> 2. Measure
> 3. Measure

Also:
1. Don't.
2. Don't... yet.
3. Profile before optimizing

See for instance
http://www.moscowcoffeereview.com/programming/the-3-rules-of-optimization/
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Ranier Vilela-2
Em seg., 16 de nov. de 2020 às 10:26, Luiz Henrique de Figueiredo <[hidden email]> escreveu:
> You know the first three rules of optimisation, right?  They are, in order:
>
> 1. Measure
> 2. Measure
> 3. Measure

Also:
1. Don't.
2. Don't... yet.
3. Profile before optimizing

See for instance
http://www.moscowcoffeereview.com/programming/the-3-rules-of-optimization/
IMHO, Lua is where it is, why you never heard that.
How many times have you heard the same criticisms and made the fastest dynamic language in the world?

regards,
Ranier Vilela
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Sean Conner
It was thus said that the Great Ranier Vilela once stated:

> Em seg., 16 de nov. de 2020 às 10:26, Luiz Henrique de Figueiredo <
> [hidden email]> escreveu:
>
> > > You know the first three rules of optimisation, right?  They are, in
> > order:
> > >
> > > 1. Measure
> > > 2. Measure
> > > 3. Measure
> >
> > Also:
> > 1. Don't.
> > 2. Don't... yet.
> > 3. Profile before optimizing
> >
> > See for instance
> > http://www.moscowcoffeereview.com/programming/the-3-rules-of-optimization/
>
> IMHO, Lua is where it is, why you never heard that.
> How many times have you heard the same criticisms and made the fastest
> dynamic language in the world?

  Um ... you do know that Luiz Henrique de Figueiredo maintains Lua, along
with Roberto Ierusalimschy.  If you are waiting to hear back from Team Lua,
I think this is it.

  -spc
Reply | Threaded
Open this post in threaded view
|

回复: Lua 5.4.2 New assorted suggestions (Part II)

崔 献军
In reply to this post by Chris Smith
pardon sir, I have a question with no relevent lua. 
I have subscribed lua mail list for some time with microsoft out look, but recently I found  the lua mails are automatically marked
as trash and be put in trash box. 

I dont set any filter conditions for my outlook mailbox,  so i want to get help from anyone to solve this question.
thanks a lot.

发件人: Chris Smith <[hidden email]>
发送时间: 2020年11月16日 21:08
收件人: Lua mailing list <[hidden email]>
主题: Re: Lua 5.4.2 New assorted suggestions (Part II)
 

> On 16 Nov 2020, at 13:03, Ranier Vilela <[hidden email]> wrote:
>
> Usually I write optimized code, it has worked for me.

You know the first three rules of optimisation, right?  They are, in order:

1. Measure
2. Measure
3. Measure

Show that there is a problem.  Show that there is a measurable benefit to fixing it.  Show that your ‘fix’ works and backs up your claims.

Chris

Chris Smith <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Tim Hill
In reply to this post by Luiz Henrique de Figueiredo


> On Nov 16, 2020, at 5:26 AM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
>
>> You know the first three rules of optimisation, right?  They are, in order:
>>
>> 1. Measure
>> 2. Measure
>> 3. Measure
>
> Also:
> 1. Don't.
> 2. Don't... yet.
> 3. Profile before optimizing
>
> See for instance
> http://www.moscowcoffeereview.com/programming/the-3-rules-of-optimization/

I’ll be honest .. I REALLY dislike this “premature optimization” aphorism. It (and rules like it) are often quoted as if they are laws of physics, when in fact they are at best vague generalizations.

First, lua is already a *massively* optimized language, which is one of its attractions. The leanness of the language, VM, and libraries is a testament to that. So saying you should not optimize Lua seems dubious (I’m not defending the OPs changes, I’m talking in general here).

Second, the idea that optimization is something that can be “bolted on later” when something is found to be sub-performant applies only to certain very limited cases, mostly related to local implementation details. It certainly does NOT apply to, for example, architectural design, when “optimization” can often mean “start over”.  Should we use a bubble sort, and only later switch to (say) quicksort when we have carefully “proved” that it is too slow? Or write a video Codec in Perl, and then act surprised when it cannot process video data in real time?

What SHOULD be explained is that the choice of when to optimize (if ever) should be based on the *cost* of that optimization effort and the *probability* that it will be needed. Changing fundamental architectural design is massively expensive, as is re-writing a complex software system in a new language. That is why these decisions *must* be optimized up-front .. and quoting “we can optimize that later” is, in these cases, nonsense.

The very phrase “premature optimization” in fact gives a lie to itself. What do we mean by “permature”? If you mean “when you find the program does not perform as expected” then (as I have explained) you are going to be out of luck in most cases.


—TIm


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Sean Conner
It was thus said that the Great Tim Hill once stated:

> > On Nov 16, 2020, at 5:26 AM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> >
> >> You know the first three rules of optimisation, right?  They are, in order:
> >>
> >> 1. Measure
> >> 2. Measure
> >> 3. Measure
> >
> > Also:
> > 1. Don't.
> > 2. Don't... yet.
> > 3. Profile before optimizing
> >
> > See for instance
> > http://www.moscowcoffeereview.com/programming/the-3-rules-of-optimization/
>
> I’ll be honest .. I REALLY dislike this “premature optimization” aphorism.
> It (and rules like it) are often quoted as if they are laws of physics,
> when in fact they are at best vague generalizations.
>
> First, lua is already a *massively* optimized language, which is one of
> its attractions. The leanness of the language, VM, and libraries is a
> testament to that. So saying you should not optimize Lua seems dubious
> (I’m not defending the OPs changes, I’m talking in general here).
>
> Second, the idea that optimization is something that can be “bolted on
> later” when something is found to be sub-performant applies only to
> certain very limited cases, mostly related to local implementation
> details. It certainly does NOT apply to, for example, architectural
> design, when “optimization” can often mean “start over”.  Should we use a
> bubble sort, and only later switch to (say) quicksort when we have
> carefully “proved” that it is too slow? Or write a video Codec in Perl,
> and then act surprised when it cannot process video data in real time?

  The advice isn't saying "be stupid when writing code."  By all means, use
C when writing a codec, or use the language supplied or standard library
supplied sort routines (which should be "good enough" for most cases).

  The advice to profile the code ("measure, measure, measure") is because
the bottle necks in performance may not be where we think they are.  I wrote
a Lua based program at work.  It was put into production five years ago.
The code was written in a straightforward way with no thought to
optimization---correctness was the overriding goal at the time [1].

  It was only last year that performance was a bit of a concern---not enough
to panic, but maybe we should look into it.  I did.  I was completely
surprised at the results:

        http://boston.conman.org/2019/08/21.1

  I did *NOT* expect the following bit of code to be the hotspot:

        local n = tonumber(capture,16)

  It turned out I didn't need to convert the number, and that hot spot went
away [2].  Had I tried to "optimize" the code without measuring, I would
have wasted my time.  Had I tried optimizing the code five years ago, I
again, would have probably wasted my time, as we were able to go five years
before it even hit our radar.

  Right now, it's the LPEG code that is the hot spot, which isn't
surprising.  It's not a real concern yet, but now I have the time to
investigate some other approaches.

> What SHOULD be explained is that the choice of when to optimize (if ever)
> should be based on the *cost* of that optimization effort and the
> *probability* that it will be needed.

  If the users of of the software are complaining about performance, then
you optimize by first profiling the program, identifying the hot spots and
how to speed that code up.  The best speed ups come with algorithmic changes
(a simple example is changing a linear search with a binary search, or
Quicksort with MergeSort because the input data creates a pathological case
with Quicksort).  Less so with so called micro-optimizations like changing
strcmp() with strncmp() or replacing a divide with a reciprical multiply.

> Changing fundamental architectural
> design is massively expensive, as is re-writing a complex software system
> in a new language. That is why these decisions *must* be optimized
> up-front .. and quoting “we can optimize that later” is, in these cases,
> nonsense.

  Again, not always.

  Another example (that I have to yet write about).  I wrote an HTML parser
in LPEG, but it bloated the memory footprint of the programs that use it by
eight times the original size.  I found a PEG compiler for C, and using the
existing LPEG code as a base, I was able to convert the HTML parser to C.
Not only did it decrease the memory usage (to maybe double the original
size, not the eight times of the Lua version) but it ran in about 1/10 the
time as well.

  It wasn't a drop-in replacement, but it wasn't a drastic change either:

        dom = html:match(doc)

to

        dom = html(doc)

  But again, before I went to the trouble, I did double check to make sure
it was the LPEG HTML parser that was causing the bloat and not something
else (it was the cause).  You don't have to rewrite the *entire* thing in a
different language if you can replace a bit in a different language.

> The very phrase “premature optimization” in fact gives a lie to itself.
> What do we mean by “permature”? If you mean “when you find the program
> does not perform as expected” then (as I have explained) you are going to
> be out of luck in most cases.

  Not in my experience.  The only time I failed to optimize a program
properly (dropping the run time from a year to a day) was because I didn't
fully understand floating point arithmatic.  In my defense, it was in
college, and the foilbies of floating point just wasn't a thing taught in
the Comp Sci department at the time (was *was* taught in the Math department
though).  It was only 25 years later did I realize my mistake.

  -spc

[1] The actual goal as I was writing it was a "proof-of-concept" using
        Lua and LPEG to do the heavy lifting and get a feel for the problem
        I was trying to solve, and then maybe to a reimplementation in C for
        speed, as it did involve processing SIP messages for a major
        cellular carrier in the US.  My manager at the time put the Lua+LPEG
        version into production, and I didn't find out until a few months
        later.

        Go figure.

[2] There were other hot stops after that, but that one was the worst
        offender, and completely surprising to me.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Roberto Ierusalimschy
In reply to this post by Tim Hill
> >> You know the first three rules of optimisation, right?  They are, in order:
> >>
> >> 1. Measure
> >> 2. Measure
> >> 3. Measure
> >
> > Also:
> > 1. Don't.
> > 2. Don't... yet.
> > 3. Profile before optimizing
> >
> > See for instance
> > http://www.moscowcoffeereview.com/programming/the-3-rules-of-optimization/
>
> I’ll be honest .. I REALLY dislike this “premature optimization”
> aphorism. It (and rules like it) are often quoted as if they are laws
> of physics, when in fact they are at best vague generalizations.
>
> First, lua is already a *massively* optimized language, which is one
> of its attractions. The leanness of the language, VM, and libraries
> is a testament to that. So saying you should not optimize Lua seems
> dubious (I’m not defending the OPs changes, I’m talking in general
> here).

But Lua was not born massively optimized :-) All (or at least most :-)
optimizations were implemented following those rules. In fact, from
time to time, we remove some "optimizations" that do not seem to
be paying off (e.g., the "stackfull" implementation).

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

eugeny gladkih-2
In reply to this post by Luiz Henrique de Figueiredo


On 16 Nov 2020, at 16:26, Luiz Henrique de Figueiredo <[hidden email]> wrote:

You know the first three rules of optimisation, right?  They are, in order:

1. Measure
2. Measure
3. Measure

Also:
1. Don't.
2. Don't... yet.
3. Profile before optimizing


anyway, usage of lua_pushlstring instead of lua_pushstring is much better.


-- 
Yours sincerely, Eugeny.
+33 6 38 52 27 93
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Roberto Ierusalimschy
> anyway, usage of lua_pushlstring instead of lua_pushstring is much better.

It depends on what you call "better". For literal strings,
lua_pushstring is both simpler to use and faster. For mutable
strings, lua_pushstring may not be even correct. (The string
might contain embedded zeros.)

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Ranier Vilela-2
Em sáb., 21 de nov. de 2020 às 13:13, Roberto Ierusalimschy <[hidden email]> escreveu:
> anyway, usage of lua_pushlstring instead of lua_pushstring is much better.

 For literal strings, lua_pushstring is both simpler to use and faster. 
lua_pushstring(L, "cannot close standard file");
Can be simpler, but it is not faster than:

/* avoid strlen call or inline */
lua_pushlstring(L, "cannot close standard file", sizeof("cannot close standard file") - 1);

Another example:
void luaT_init (lua_State *L) {
  static const char *const luaT_eventname[] = {  /* ORDER TM */
    "__index", "__newindex",
    "__gc", "__mode", "__len", "__eq",
    "__add", "__sub", "__mul", "__mod", "__pow",
    "__div", "__idiv",
    "__band", "__bor", "__bxor", "__shl", "__shr",
    "__unm", "__bnot", "__lt", "__le",
    "__concat", "__call", "__close"
  };
  unsigned int i;
  for (i=0; i<TM_N; ++i) {
    G(L)->tmname[i] = luaS_newlstr(L, luaT_eventname[i], sizeof(luaT_eventname[i]) - 1); /* build-time size */
    luaC_fix(L, obj2gco(G(L)->tmname[i]));  /* never collect these names */
  }
}

For mutable strings, lua_pushstring may not be even correct. (The string
might contain embedded zeros.)

/* mutable mylargestring with 1Gb size, which certainly *does not* contain zeros. */
lua_pushstring(L, mylargestring); /* always calling strlen or inline */

/* mutable mylargestring with 1Gb size, which certainly *does not* contain zeros. */
lua_pushlstring(L, mylargestring, len); /* avoid strlen call or inline */
 
Ranier Vilela
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Luiz Henrique de Figueiredo
> /* 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.
12