[Opensim-dev] Upcoming work on alternative client stack

[Hurliman, John]

-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Mike Mazur
Sent: Monday, August 18, 2008 5:16 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Upcoming work on alternative client stack

Hi,

On Mon, 18 Aug 2008 16:07:45 -0700
"Hurliman, John" <john.hurliman at intel.com> wrote:

> From my testing, any time you deal with a P/Invoke wall you need to
> seriously evaluate whether it is worth it.

I'd just like to clarify a few things.

First, I'm not trying to do any P/Invoke stuff. The funsl stack I'm
working on is strictly C# managed code. The C/C++ files generated by
the compiler can be used in other projects if they are developed in C
or C++.

Second, the performance bottlenecks were mainly with the GC. We found
that during login the number of GC events increased dramatically. The
solution for this is a working PacketPool. There's also the issue of
unpacking the entire packet every time it comes in, immediately as it
comes in, when all that's needed is a subset of the data. The solution
to this is lazily extracting the data right before the client stack
calls out to the core.

Thanks,
Mike


Ahh, I misunderstood and thought this was an unmanaged/managed hybrid.
Anything that reduces heap allocations / fragmentation is going to be a
big win. That's what my work with the types has been focusing on. Let me
know if you start looking at the PacketPool, I don't have free cycles to
dedicate to it right now but I have drafted some ideas out on paper. As
far as unpacking the entire packet, I made the design assumption that
you want to access all of the data in a packet at some point, or at
least enough of it that it makes sense to decode the entire thing in a
single pass. The way SL packets are laid out means you have to parse
through the entire thing up to the field you are interested in, because
of variable field and block sizes. Stuffing the incoming UDP buffers in
a queue and delaying decoding could address your latter issue.
Regardless, I'm interested in any possible new methods of handling
packet decoding/encoding and will lend a hand to profiling and
comparison when the code is ready.

John