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

[Coroutines <coroutines@...>]

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.

2) I thought there may be a penalty associated with how big the buffer
is, but when I checked to see what the default allocated size is -- I
found an optinteger() setting that to 1500.  The packet sizes should
have been 1450 so I don't think there was a problem here -- from how
the :byte() code looks I thought it was returning memory Lua "owned"
but was actually past the buffer, however.  I don't think it should
affect speed, just scary?

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