This fixes the problem I previously posted regrading NetworkStream Read/Write
Timeout properties.
Index: Socket.cs
===
--- Socket.cs (revision 101631)
+++ Socket.cs (working copy)
@@ -1166,9 +1166,12 @@
Hello,
This patch seems to be the cause of the build failures on Win32:
http://mono.ximian.com/monobuild/python/monobuild.py/packagestatus?platform=win-4-i386&package=mono&HEAD_or_RELEASE=HEAD
svn rev 102051 does not seem to cause the error on my machine, while svn rev
102052 causes the crash
Hi,
> I get an 10% performance boost (give or take). Surely if the method was
> getting inlined, that wouldn't be the case. Could it be that the temp
> variables (25->28) aren't being dropped and there is excess variable copying
> going on?
Yes, the current JIT is not very good at getting rid of
Hi,
The method ch does get inlined alright:
INLINE START 00B23210
System.Security.Cryptography.SHA256Managed:ProcessBlock (byte[],int) ->
System.Security.Cryptography.SHA256Managed:Ch (uint,uint,uint)
created temp 24 of type System.UInt32
method to IR System.Security.Cryptography.SHA256Managed:Ch
Hi,
On my amd64 machine, that method does get inlined. You can check the
output of mono -v -v -v -v for INLINE lines to see what gets inlined.
Zoltan
2008/4/30 Alan McGovern <[EMAIL PROTECTED]>:
> This method does not get inlined:
>
> private uint Ch (uint u, uint v, uin
I just checked the R01/R02 methods and they both have 20 IL instructions
with 22 bytes of IL code, so this is pretty much a corner case. However the
Ch method that you mention has a mere 9 IL instructions and only 9 bytes of
IL code, so this does not explain why it doesn't get inlined if the
thresh
Hi,
That makes sense. I was just quite surprised at the time that the methods
were not being inlined as they were only simple maths operations. I checked
monodis for one of the methods and it turned out to be 8 IL instructions,
which is probably 24 bytes, which would explain why it wasn't inlined.
Hey Miguel,
On 5/1/08, Miguel de Icaza <[EMAIL PROTECTED]> wrote:
> The problem with this discussion is that you guys did not understand the
> reason for the current split.
That's not very fair, i think we do.
The main point was saying that currently, for the traditional .net
aware programmer,