Hi again, On 3/30/07, Joe Shaw <[EMAIL PROTECTED]> wrote: > That huge object array, in turn, is referenced by > System.Collections.Queue -> System.Net.Socket.Socket, specifically the > readQ member. So basically it means that the readQ member in > System.Net.Socket.Socket is a huge Queue, which internally has an > object array, which apparently has millions of SocketAsyncResult > objects inside. So how those are being allocated? > > These objects are created a lot[...]
I got a little ahead of myself here: I'm obviously looking at the code for System.Net.Sockets.Socket here. > I don't know much about the Socket class and how the async IO > works, but it boils down to the fact that BeginReceive() is being > called probably millions of times, but it doesn't look like Complete() > is being called enough (or possibly at all) to balance the load. I actually noticed something else: The object array in question has an average size of 10.6 megs, but it only holds 56 references to SocketAsyncResult at the time of this snapshot. So this seems to indicate to me that the enqueues and dequeues do ultimately match up, but that the allocation pattern is bad and probably not interspersed. That is, enqueue, enqueue, dequeue, dequeue, enqueue, enqueue, etc. would mean that an array could be as small as 2 items and still work for N items, assuming a 1:1 match.. But if the pattern is instead, enqueue, enqueue, enqueue, enqueue, dequeue, dequeue, etc. then it would have to be at least N. Now pretend N is a million. :) Joe _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
