Could be made faster with some sort of reverse string lookup table,
but it doesn't seem worth the overhead right now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3352 542714f4-19e9-0310-aa3c-eee0fc999fb1
there will be relatively few of those (at most one per client that is
experiencing lag) and while the client is experiencing lag we will be
trying to write their data once per pass through the sockets (which could
be hundreds of times a second) and we don't want each write attempt to
result in the creation of a temporary direct buffer.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3345 542714f4-19e9-0310-aa3c-eee0fc999fb1
another instance of append() that needed to be changed to appendLoud().
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3343 542714f4-19e9-0310-aa3c-eee0fc999fb1
Queue.append() only does a notify() if the queue was previously empty.
So when the dobj thread was requesting two sounds one after another, it
only woke up one player thread, which played the first sound and then
came back 'round to play the next sound after it was done. The next sound
was usually expired by that time.
Use queue.appendLoud(), which always wakes up a waiter thread.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3342 542714f4-19e9-0310-aa3c-eee0fc999fb1
getting dropped because they're taking too long to play. Extended the
max delay to 1000ms, which will surely help more sounds play, but may
not be worth it. Hey, we've got a test server to test on...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3337 542714f4-19e9-0310-aa3c-eee0fc999fb1
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: svn+ssh://src.earth.threerings.net/narya/trunk@3336 542714f4-19e9-0310-aa3c-eee0fc999fb1
sufficiently incompatible with GNU make that I'd rather just have two
whole separate goddamned directories with their own Makefile than try
to get everyone to agree on how to do things.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3328 542714f4-19e9-0310-aa3c-eee0fc999fb1
the throes of a previous connection. Also don't spuriously recreate our
ticker because it's very possible for logon() to be called and not
logoff(), logon() might fail, for example.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3321 542714f4-19e9-0310-aa3c-eee0fc999fb1
has been changed, except the names to protect the innocent.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3316 542714f4-19e9-0310-aa3c-eee0fc999fb1
changed the output format to be the same as the one for DObjectManager
profiling output.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3309 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne