-list@lists.ximian.com
Subject: Re: [Mono-dev] Fundamental performance problems with Mono
Hi Miguel,
The purpose of System.ServiceModel.Channels.BufferManager in WCF is to
allocate buffers from a pool. The current implementation in Mono is
marked [MonoTODO] and only returns a single buffer. Not only
Robert Jordan wrote:
> So you're actually blaming a wrapper whose solely intention was
> to gain .NET 2.0 compatibility.
>
To me, that looks like a very good target for blame - a lame
implementation done in
a hurry to tick a box.
> Patches welcome :)
>
I'd personally be much more comfortable
damageboy wrote:
> By this, I mean that a fundamental difference you'll find in the Linux world
> from the Windows world is that there is no async socket API for Linux. This
> is a "limitation" (if you want to call it like that) of the Linux kernel,
> and in no way related to mono.
>
That's a li
@lists.ximian.com
Subject: Re: [Mono-dev] Fundamental performance problems with Mono
Hello Thad,
> If you do decide to go with managed buffers you'll need to implement
> your own (or find a good library) as the WCF BufferManager in Mono
won't
> really do what you want.
Can you de
Hello Thad,
> If you do decide to go with managed buffers you'll need to implement
> your own (or find a good library) as the WCF BufferManager in Mono won't
> really do what you want.
Can you describe what are the limitations in Mono's Buffer Manager?
Miguel.
__
Robert Jordan wrote:
>
> The new GC won't help in this special case.
>
why not? Even when using the Begin\End API, a generational GC could get rid
of all the garbage this API creates during the fast gen 0 collections (at
least this is what happens with Microsoft's GC on Windows).
Robert Jor
mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Fundamental performance problems with Mono
Did you see this improvement using Mono or .NET on Windows? in your blog post
you talk about GC generations that don't exist in Mono GC and OOM exceptions
that I don't get.
I am also
On 08.01.2010 13:14, Stifu wrote:
>
> Hi,
>
> You may already know, but Mono 2.8 will have a brand new GC... This may
> improve your app performances.
The new GC won't help in this special case.
>> Therefore, I do blame Mono for the poor performance. If the epoll+I/O
>> Thread pool model is imple
n...@lists.ximian.com
> [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of zvikag
> Sent: Thursday, January 07, 2010 10:38 AM
> To: mono-devel-list@lists.ximian.com
> Subject: [Mono-dev] Fundamental performance problems with Mono
>
>
> Hello all,
> The bottom
Hi,
You may already know, but Mono 2.8 will have a brand new GC... This may
improve your app performances.
zvikag wrote:
>
> Hi,
>
> Writing my server in a managed language, be it Mono or Java, is a basic
> choice of effectiveness over cost. I prefer good performance in no time
> than super-g
Hi,
Writing my server in a managed language, be it Mono or Java, is a basic
choice of effectiveness over cost. I prefer good performance in no time than
super-great-performance that takes ages to develop and will almost surely
rain upon me bugs from hell. And if you write your managed code correc
Hi Zvika,
I'll start by saying that I've been there, I've also seen abysmal
performance with the mono async socket implementation.
If you'll dig down in the code (I did so last time around Mono 2.2) you
should also see that there is no such thing in Mono/Linux at any rate...
By this, I mean that a
Providing a simple benchmark program that highlight the limitation in mono's
Socket
implementation would help a lot.
Our generational GC is evolving quite fast and you can try it now to see how
it performs
under your program. Build instructions can be found on the list history.
Besides that, feel
riginal Message-
From: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of zvikag
Sent: Thursday, January 07, 2010 10:38 AM
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] Fundamental performance problems with Mono
Hello all,
The bott
Hi,
Could you also share some test code so we can gain a better
understanding of the issue/s?
Thanks,
pablo
On 07/01/2010 16:37, zvikag wrote:
>
> Hello all,
> The bottom line of this message is that I don't see how can one write a
> high-performance socket server in Mono...
> Here is the sto
Hello all,
The bottom line of this message is that I don't see how can one write a
high-performance socket server in Mono...
Here is the story:
I am writing a proxy server using .NET Socket API. This proxy does almost
entirely I/O work - copying buffers from one socket to another. Now, Mono
doesn'
16 matches
Mail list logo