Re: Speed of Lua's immutable strings vs buffers (split from Re: Pooling of strings is good)

[Sean Conner <sean@...>]

It was thus said that the Great Coroutines once stated:
> On Mon, Aug 25, 2014 at 4:05 PM, Coroutines <coroutines@gmail.com> wrote:
> 
> > I *want* to disagree with how this benchmark is done because even if
> > the networking portion of this comparison is done correctly it's using
> > your socket library and I have my own -- and others have luasocket.
> > It would take some time to properly critique all 3 and even set up all
> > 3 for this benchmark to get a fairer view of things.
> >
> > I'm going to try to take a day to look at all of this but I want to
> > point out that in suck.lua `data' is a local defined within the block
> > -- it is created from the :recv() call on every iteration.  In
> > suckb.lua `data' is a global declared on line 61 -- I think the global
> > lookup as `data' is passed to :recv() might have some cost in this.  I
> > don't believe this should make very much of a difference -- if these
> > results are to be believed I'm shocked you can get away with
> > allocating such a large buffer for the string-returning :recv() so
> > often.
> >
> > Besides that, I think your recv()/recvb() functions could be "faster"
> > for both/overall if they avoided allocating for the peer address
> > userdata/sockaddr -- you can get the remote peer information with
> > getpeername().  As I'm sure you know, recv/recvfrom/recvmsg are
> > functions that are expected to be called quite often -- allocating for
> > the peer sockaddr is bad (imo) on every call to them.  I also think
> > it's odd that recv() calls recvfrom(), but there should be no
> > difference in the results.
> 
> I'm adding to what I mentioned previously -- here is what I have
> looked at so far:
> 
> 1) I'm not sure I understand the idx in the buffer struct.  When you
> recvb() it gets set to the next available/free index within the
> buffer.  When you call :byte() it seems to return the byte at the
> index you provided offset by idx.  I'm pretty sure idx is meant to
> note the next free index within the buffer (and therein the length of
> the used portion), but I think the :byte() function might be incorrect
> as it returns bytes from the unused part of the buffer?
> https://github.com/spc476/lua-net-speed/blob/master/buffer.c#L83  If
> this is wrong, fixing it should not affect the benchmark -- I'm just a
> little confused there.

  Hmm ... bad names for the fields.  Rename len to max, and idx to len.

  Since the buffer is to be reused, and I know how I'm using the buffer,
recvb() reads into the buffer starting at offset 0.  It then sets idx to the
number of bytes read.  buffermeta_byte() uses idx as the length of the
"string".

  Okay, the names are bad, and it assumes a particular usage.  What can I
say, it's proof-of-concept code.

> Seems like immutable, pooled strings are still winning on speed though :-)

  Yup.

  -spc