Re: String buffers (was Re: why creating a ffi.ctype "double [1]" is slow?)
- From: Daurnimator <quae@xxxxxxxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Fri, 13 Mar 2015 12:50:33 -0400
On 13 March 2015 at 12:25, Mike Pall <mike-1503@xxxxxxxxxx> wrote:
> Daurnimator wrote:
>> On 2 May 2014 at 15:54, Yichun Zhang (agentzh) <agentzh@xxxxxxxxx> wrote:
>> > CloudFlare is going to sponsor Mike Pall to implement a built-in
>> > string.buffer API in LuaJIT v2.1 soon :) And it will be JIT compiled
>> > ;)
>>
>> What happended with this?
>
> Lack of time on my side.
>
> Also, there's the general issue of a string buffer API vs. a
> string buffer type. The latter would be a major change in the VM
> (and various APIs), but it would cover more use cases.
>
> The typical problem with a pure API is that filling the string
> buffer may be fast, but eventually you'll need to convert it to a
> regular string type, before it can be passed to any other function
> (like io.write). That conversion is expensive, since it involves a
> copy plus string interning, i.e. GC overhead. But avoiding that
> overhead is precisely why you'd want to have a string buffer in
> the first place.
I was imagining something like the luaL_Buffer api but in lua.
It's common enough that I need to build an outgoing packet, which ends
up looking like:
-- in initialser
self.data = {}
--some sort of append_string method
table.insert(self.data, string.char(3))
table.insert(self.data, "foo")
--some sort of 'end of header' method
table.insert(self.data, "\r\n")
-- then in 'render' method:
return table.concat(self.data)
This hits several NYIs including string.char and table.concat.
I was thinking a string builder api might make this traceable?
> Mucking with all builtins that might take a string to accept a
> non-integrated string buffer type is a lot of work (and doesn't
> solve the issue for non-builtins). Alas, adding a general string
> buffer type that can be used in place of a string everywhere is
> even harder, since it's an afterthought (and it'd break some
> traditional API uses, too). I don't think this is feasible within
> the current Lua ecosystem (*cough*).
I hadn't even considered that you'd want to pass the string buffer to
string* builtins.
I don't think I have a use case for it.
Though something like the new lua 5.3 string.pack/unpack apis might be useful.
Other related posts:
