Hello!
On Sun, Mar 16, 2014 at 5:01 PM, Brian Akins wrote:
> I have an app that mostly fetches from a shared dict and prints using
> ngx.print. I noticed that both of those copy the data, so I'm copying the
> data around unnecessarily.
>
the shdict API copies the data from the shm slabs to the Lua VM, and
then the data gets copied from Lua VM to the nginx output buffers.
You could save the trip through the Lua VM if you don't want to do any
processing in Lua VM. I think you still need to copy to the nginx
temporary output buffers here because the shm slabs may get overridden
when nginx is still trying to write it out to the system socket send
buffers. They have different lifetime here per se.
> Note: I haven't observed any issues with this so this may be a premature
> optimization.
I suggest that we only optimize based on profiling results (like
flame graphs) :)
> Using the new functions exposed for ffi usage, I can avoid the copy on the
> shdict get. I was looking at ways to "write" a Lua string to the network
> without copying it.
> I was thinking I could ref it using luaL_ref, add it to
> output chain, and register a cleanup that does the luaL_unref. I wasn't sure
> how this would work with the coroutines, etc.
>
This looks more expensive to me for common use
cases :)
> Thoughts? Should I not worry about this at all?
>
I suggest we focus on eliminating unnecessary dynamic memory
allocations, which are way more expensive than data copying according
to all the on-CPU flame graphs that I've ever seen for nginx :)
For example, I mentioned saving the intermediate Lua strings from
shdict to the nginx output buffers, which save allocations (and GC
overhead) of the Lua string objects ;) Though this use case is also
very limited because most of the times, we want to do something with
the data in Lua.
Thanks!
-agentzh
