On Thu, 29 Mar 2007 11:28:49 -0400, Miguel de Icaza [EMAIL PROTECTED]
scribbled:
Hello,
Please review a performance optimization for HttpRequest.Headers and
HttpRequest.ServerVariables collections.
It implements lazy collection fill because most common flow is to ask
for value by name.
To the Gendarme gurus,
I don't know if the GC is smart enough to Dispose of resources for us, but I
will assume that it does not hurt to help it. There are two patterns that
Gendarme could look for.
class Foo
{
Foo()
{
IDisposable resource = new Resource();
throw new
Hi All,
I am making a winform gui for monotorrent and I see with moma that some
properties are missing to make my code compile on mono. So I just code a basic
structure for missing class but it is still unfinished (Monotodo attributes)
because I do not know very well the internal things of mono
Hello Vladimir,
On Thu, 2007-03-29 at 09:42 -0400, Vladimir Giszpenc wrote:
To the Gendarme gurus,
I don't know if the GC is smart enough to Dispose of resources for us,
but I will assume that it does not hurt to help it. There are two
patterns that Gendarme could look for.
Side node:
Hi Alan,
On 3/29/07, Alan McGovern [EMAIL PROTECTED] wrote:
I ran it again, and came up with this (startling ;) ) figures for
allocations:
1) type=System.Runtime.Remoti...ing.MonoMethodMessage 4185
1024.1M 256603.6 0.5
System.Threading.ThreadPool:QueueUserWorkItem
Hi,
On 3/30/07, Miguel de Icaza [EMAIL PROTECTED] wrote:
One question: how do I enable the four different profiling modes for
HeapBuddy?
The summary mode is the default. For the others, you just provide the
relevant word on the command line. history, types, backtraces.
You can also turn off
Hey Olivier!
Thanks for your patch! I took it and added the implementation and tests
as well. It is committed in SVN as r75208.
Please read up on our coding guidelines
(http://www.mono-project.com/Coding_Guidelines) if you submit more stuff
in the future. I fixed it all this time, but next
Hi,
Yep, that's your problem right there. ;) Also, if you look at the
summary you posted, you'll notice that in the course of 1 second, you
have 9 resizes going from a size of 2.8 megs to 322.6 megs.
Yup, i had noticed that ;) There is something fishy, but i can't find out
what it is. I've
Hi Alan,
If you can run your application on Windows, check this tool which can
help to find where's located memory leak:
http://www.microsoft.com/downloads/details.aspx?amp;amp;displaylang=enfamilyid=9bfa49bc-376b-4a54-95aa-73c9156706e7displaylang=en.
This guide can also help:
Just a quick update, i think my email bounced due to the attached heap-shot
data. I'm now hosting it here:
http://www.megaupload.com/?d=QOJKRWT2
If theres problems with that, let me know.
Alan.
On 3/30/07, Marcos Cobeña Morián [EMAIL PROTECTED] wrote:
Hi Alan,
If you can run your
From your e-mail, it seems to be those AsyncSockets not disposing as
expected
Even if i wasn't disposing of them at all, i connect to at most 5 people a
second, so that's at most 5 sockets being created a second. There's no way
that they would lead to such a huge allocation rate. Also, i can
Hi,
I gave that a shot, but i can't actually make use of it :( The problem is
that the memory usage goes from 20 megabytes to 2 gigabytes in the space of
2 seconds. I can't get a snapshot of anywhere in between and once memory
usage rockets up there, i can't take a snapshot using the tool.
So
Hey,
On 3/30/07, Alan McGovern [EMAIL PROTECTED] wrote:
Yup, i had noticed that ;) There is something fishy, but i can't find out
what it is. I've run heap-shot and attached and emailed the results in
already. Hopefully they'll make sense to someone. By the looks of it,
there's some kind of
I'm trying to port the mono runtime to a device called a Wii. Although it
has a PowerPC based CPU, I think getting it running with the interpreter
first would be the best approach rather than attempting to patch up the
existing PowerPC JIT, but I can not seem to find any documentation that
would
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
AFAIK, the interpreter was discontinued.
:)
On 3/30/07, John Matzen [EMAIL PROTECTED] wrote:
I'm trying to port the mono runtime to a device called a Wii. Although it
has a PowerPC based CPU, I think getting it running with the interpreter
first would be the best approach rather than
Hello,
I'm trying to port the mono runtime to a device called a Wii.
Although it has a PowerPC based CPU, I think getting it running with
the interpreter first would be the best approach rather than
attempting to patch up the existing PowerPC JIT, but I can not seem to
find any documentation
Miguel de Icaza wrote:
Hello,
I'm trying to port the mono runtime to a device called a Wii.
Although it has a PowerPC based CPU, I think getting it running with
the interpreter first would be the best approach rather than
attempting to patch up the existing PowerPC JIT, but I can not seem
Just to let you know since I did something very similiar for XBOX360 :
Even if I was able to make glib and then mono compile on XBOX360 (it was a bit
painful but doable) and it generated valid code to execute at runtime,
nevertheless memory protection against execution of user allocated area
Hello,
When I checked about using the interpreter, I've read somewhere that it wasn't
up to date anymore (maybe the info was too old and it's now up to date to
execute everything, anyone can confirm ?).
It still builds, but no maintenance has gone into it. It is also
missing important
Hello,
prevented me to continue (you can check the blog post I did about that on
http://dev.kalimdor.org/entropia/).
I read somewhere that some of those restrictions were being lifted, am I
incorrect?
Miguel
___
Mono-devel-list mailing list
Hello,
Just to let you know since I did something very similiar for XBOX360 :
Even if I was able to make glib and then mono compile on XBOX360 (it was a bit
painful but doable) and it generated valid code to execute at runtime,
nevertheless memory protection against execution of user
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
Hi,
On 3/30/07, Alan McGovern [EMAIL PROTECTED] wrote:
That leaves me with the question of how the hell a SocketAsyncResult is 10
megs in size!
It's not the SocketAsyncResult itself that's 10 megs in size, it's the
object array that holds them that is 10 megs in size.
I'm going to do a bit
Ok, i did a quick bit of testing on my code.
Firstly, the 54 instances of SocketAsyncResult do make sense. Typically
there will *always* be a pending BeginReceive on every socket i have opened.
Therefore 54 instances of SocketAsyncResult would correspond to 54 open
connections, which is pretty
I've been trying to compile SVN head on both windows and MacOS and it fails
on both. Is this a problem on just my side, or is compilation actually
broken? I've attached the last 100 or so lines of output when trying to
build on Mac OS X. If anyone has any ideas, let me know.
Thanks,
Alan.
gcc
On 3/30/07, Alan McGovern [EMAIL PROTECTED] wrote:
I've been trying to compile SVN head on both windows and MacOS and it
fails on both. Is this a problem on just my side, or is compilation actually
broken? I've attached the last 100 or so lines of output when trying to
build on Mac OS X. If
27 matches
Mail list logo
