Hi, That leaves me with the question of how the hell a SocketAsyncResult is 10 megs in size! The size of the largest single object in my entire code is a 16kB byte[] buffer. If each SocketAsyncResult is 10 megabytes in size, i have to question the internal workings of mono, as i know from profiling my own code does *not* create objects anywhere near that size.
I'm going to do a bit of profiling to count how many socket BeginXXX calls are made from my own code as compared to the EndXXX calls to see how they match up. Is there any way of finding out what exactly is inside those SocketAsyncResults that is 10 megs in size? I can verify that the exact same code running under Mono 1.2 and earlier does *not* exhibit the same behavior, everything works fine. I only came across this bug after updating my mono installation to 1.2.3. This is why i think it's a mono bug, however i can't reproduce the problem in the form of an NUnit test. Thanks again, Alan. On 3/30/07, Joe Shaw <[EMAIL PROTECTED]> wrote:
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
