Here's a giant performance improvement: the current Presents architecture flattens messages into a buffer and then passes that bucket to a SocketChannel.write() method which is part of the NIO business. If said buffer is a "direct" buffer, the write() method will in theory do high-performance shit like DMA the data right to the network card. If it's not a direct buffer, Sun apparently makes a temporary direct buffer, copies the data into it and passes that on to the underlying socket send() call. We weren't using direct buffers which means that we were copying everything one more time than needed (not a huge deal) and that we were allocating a direct buffer for every message (a much bigger deal). This should take a serious load off of the I/O thread and fortunately we can test it on Ice to make sure it doesn't do anything super crazy.
Here's a giant performance improvement: the current Presents architecture
flattens messages into a buffer and then passes that bucket to a
SocketChannel.write() method which is part of the NIO business. If said
buffer is a "direct" buffer, the write() method will in theory do
high-performance shit like DMA the data right to the network card. If it's
not a direct buffer, Sun apparently makes a temporary direct buffer,
copies the data into it and passes that on to the underlying socket send()
call. We weren't using direct buffers which means that we were copying
everything one more time than needed (not a huge deal) and that we were
allocating a direct buffer for every message (a much bigger deal). This
should take a serious load off of the I/O thread and fortunately we can
test it on Ice to make sure it doesn't do anything super crazy.

All this said, this whole business is going to change when I rearchitect
Presents to avoid the potential race conditions it suffers from now and we
won't be able to use a single direct buffer to write all of our outgoing
messages, but I believe we will be able to use a pool of direct buffers
with one used by every message in the queue waiting to be written
(hopefully that won't be too many at any given time) which we can keep
around to avoid the expense of allocating and freeing direct buffers.


git-svn-id: a1a4b28b82a3276cc491891159dd9963a0a72fae@3336 542714f4-19e9-0310-aa3c-eee0fc999fb1

threerings/narya,threerings/narya,threerings/narya,threerings/narya,threerings/narya