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 3:02 PM, Sean Conner <sean@conman.org> wrote:

>   So, the code.  It's all here:
>
>         https://github.com/spc476/lua-net-speed

Hmm.

Okay, first I want to say that I really appreciate you going through
all the effort to bootstrap this comparison.

I think we may have a misunderstanding though -- my objective was
mostly to save on reallocating the same buffer, as I cannot mutate it
once it becomes a string.  I think there might be a potential for this
to be faster by always having a fixed-sized buffer allocated to copy
out to a string (if needed), but mostly this was about avoiding
duplicating the buffer that gets recv()'d into :>  I am still
interested in this comparson on speed, however.

>   I am willing to conceed an error in my methodology, but the ball is now in
> Coroutines' court to show where I am in error.

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.

You did a fair benchmark iterating over every :byte() in the buffer
and string -- I think this is also a fair benchmark in terms of
"real-world" usage even if I feel it should have just been focused on
duplicating and running the string library over a mutating userdata.
I would just like to point out that I am trying to use string.find()
or string.match() on the string/buffer I get from :recv() -- this
would be my common usage.  string.find() search through the string or
buffer/userdata faster than doing it byte-by-byte from Lua -- how I
use string.match() would typically create smaller strings from the
"recv buffer" (whatever it is), but locating what to substring would
go faster than traversing the buffer from Lua (the pattern-matching C
stuff would do it for me).

>   On a related note---for drastic changes like introducing mutable strings
> to Lua, it should be up to the presenter to do the work, to do the
> implementation (even if it does duplicate code) to show the idea is sound.
> Working code trumps wishes and laments.  I applaud Jan Behrens' work on
> ipairs because he's taking the time to implement his ideas.

Twist that dagger a little deeper, eh? :p  Introducing a buffer type
and metatable interface to it was not my idea.  I was hoping to learn
from upstream how I might trick Lua's typechecking functions into
believing userdata were strings and getting it to safely access the
->buf portion of the userdata (rather than the similar data member in
the TString struct).