Which show's that as far as base libraries and feature support, Mono is almost all there with full.Net 4.0.
Seeing as that's the latest version of.Net and not even the latest version that a lot of businesses are targeting, would suggest that Mono isn't lagging at all.
I had exactly the same thing happen; the only odd thing was - I hadn't paid for my WOW account since January, then and old friend noticed that my character was logged in.
Actually, the MS.Net framework ships with a tool called NGEN, the Native Image Generator.
I'll quote Wikipedia as it puts it more eloquently then me:
The native image generator (NGEN) produces a native binary image for the current environment. The byte-code is either skipped entirely or converted into native CPU instructions completely before runtime.
There is a caveat though:
NGEN is intended to make the assembly execute faster by removing the JIT compilation process at runtime, but this does not always improve performance because some optimizations can be done only by a JIT compiler (i.e. if the JIT compiler knows that the code is already running with full trust, it can skip certain expensive security checks). Because of this fact, it makes sense to use NGEN only after benchmarking the application performance before and after it.
I normally don't like to post like this but I feel moved have to respond here; people who dismiss C# because of purported Speed/Memory issues have (imho) no idea of how to program in C# properly, or have been fed a crock by people who don't know how to program in C#.
C# is like every other system out there, it has its own ways and means - it can be incredibly efficient and fast, if you use it correctly.
In fairness, even with a poorly skilled coder, a C# program can perform much better then a C++ program written with a similar amount of ineptitude; because of the way that the GC compresses your heap, causing a good chance of L2/L1 cache adjacency. I'm trying to say that I believe it's harder to write bad C# then it is to write bad C++ etc, etc.
But ok, if you want to dismiss C# just because of standard microsoft vitriol, please - be my guest:) But please don't dismiss it because you think it's slow - that's unfair and in the whole, unfounded.
Parsing problem for pretty much everything is almost universally solved by regex... As a moderate to heavy user of both Regex and XML, I cant agree with this statement; for the fact that in its proper form, Regex is not a Push-down automata and doesn't allow you to test for balanced groups/nested contructs.
If you're parsing any kind of ML with Regex, this becomes IMHO a show-stopper.
Ok ok, I know some Regex implementations implement a stack, the.Net one for example, but I find it about as clear as Klingon Algebra:)
I believe you should strive for legibility and clear layout when coding, and especially in these kinds scenarios - You'll thank yourself when you have to try and debug it 4 months down the line!
Actually, C# doesn't reference count at all, it 'Reference Traces':)
Please, let me explain; it's quite sad how often people don't get this... .Net has its block of managed memory, called the Managed heap. It's separated into 3 'generations'. This heap has 2 areas, free space and reserved space, from top to bottom.
When you allocate and object to the heap, by using the new command (object o = new object();) there is a set of rules? that have to be enforced:
Allocation occures in a contigious range of the freespace, that's as big as the size the clr determines the type to be.
The order of objects must be in the order of creation
There must be no gaps between objects
The oldest objects are in the lowest address space
The GC manages Reference tracing, and this doesn't occur when the object goes out of scope, it actually happens when the Heap is full and you attempt to allocate a new object.
In something called 'the sweep', the GC goes through each object in the heap to see if it's reachable. To do this it starts with so-called 'roots'. It then traces to see which objects are referenced by these roots.
A root identifys a storage location, which referes to objects on the managed heap, or objects that are set to null. For example, all of an applications global and static objects are considered to be it's roots. (hence the reason that all C# apps have a static void main).
When the sweep starts, it assumes that all objects are garbage.
So for each root object, it builds up a graph of the objects that root references, and marks them as being live.
However, if it finds an object that's already in the graph, it stops traversing that path.
This is two (massively) increase performance by not scanning the same object twice, and more importantly, it stops you getting into an infinite loop by scanning a circular list.
The pinch is, it prevent the circumstance that you mentioned! Because the strong reference to a linked circular list is gone, the circular list isn't attached to a root object, so it gets disposed. If you don't want it to get dropped, unless it theres a memory shortage, the C# GC also supports something called Weak References, but I'm not going to go into those here as it's headhurting:)
So once all the roots have been checked and we've got a nice graph of all the objects that are referenced by the live parts of the application somehow, the second stage of GC happens.
Any objects that haven't been touched by the walk are of course still marked as Garbage. The GC now walks up the heap linearly, looking for contigious groups of garbage which are now considered to be free space. The GC looks for the next live object and moves it to the start of this free space with a good old memcpy:)
This ofcourse invalidates all the root pointers, so the GC then updates the points in the root objects.
So now, we've got rid of all the garbage and our heap is pleasantly compacted; Take that Heap Fragmentation, Kerpow!!
But, that's not all she wrote of course:)
Now we're free'd and compacted, the 'nextObjPtr' is moved to the top of the heap. At this point the new object creation that triggered the collection is performed and the new object appears at the top of the heap.
This is a dramatic over-simplification and I've not attempted to explain finalization or weak references, but it's still good to know this stuff, it helps us as.Net programmers to consider how to write our code properly:)
The other thing I've not explained is how the Generations work:
We create a new object and the CLR realises that Gen0 is full and a sweep occurs.
Firstly, before the sweep and trash, Gen0 has the youngest objects that the GC has never seen.
Now that the sweep has finished, all the compacted obje
You make a good point, but I've just got to say that you don't need a Microsoft Language / OS / IDE to be a bad or lazy programmer. In fact, you simply need to not bother trying to understand what you're doing:)... and be too proud to admit it or realise it:)
Look around in Googles code search, there are some shockingly bad examples of code in any language you can think of:)
Indeed it's a great piece of code; the only thing that puts people off is it's apparent complexity - the whitepiper that accompanies it, is a bit offputting too...
I've had my fair share of experience with ANTs and to be honest, it's been useless in my application. We load controls dynamically in an ASP.Net environment and ANTs refuses to profile them. I've been backwards and forwards with their support team, to no avail. In fact the only thing that happened was me blocking their sales rep from emailing asking if I was prepared to make a purchase yet, when it was plainly obvious it didn't work right for us!
I've had much better experience with, and strongly recommend, the.Net Memory Profiler, from Scitech software. It's saved me so much headache:)
My First submission, apologies for the oversight.
I was just thrilled by seeing the Hacker ethos in practice and a great success from an impressive group of coders.
Slashdot Mirror
Ok, I'm not going to wholesale bite but you really need to bring some Citation to this FUD.
You see, a simple google search results in this: http://mono-project.com/Compatibility
Which show's that as far as base libraries and feature support, Mono is almost all there with full .Net 4.0.
Seeing as that's the latest version of .Net and not even the latest version that a lot of businesses are targeting, would suggest that Mono isn't lagging at all.
What about using Google Docs online ?
Me and a colleague have been using them to co-ordinate a contract we're working on and so far, it's been great.
According to his You-tube profile, this guy is from South Korea, not Japan ?
Basically this *shudder*
On the other hand, Meg has accidently introduced us to a great Bass player that I probably would have never experienced. :)
Props for that
I had exactly the same thing happen; the only odd thing was - I hadn't paid for my WOW account since January, then and old friend noticed that my character was logged in.
Weird.
Pharmacists arent Chemists
In the UK they are called that.
I believe they call them Alchemists around this part of England ...
Mind you, they still point at planes here ;)
Ahh come on, Microsoft surely can't be *that* bad to work for :)
Actually, the MS .Net framework ships with a tool called NGEN, the Native Image Generator.
I'll quote Wikipedia as it puts it more eloquently then me:
The native image generator (NGEN) produces a native binary image for the current environment. The byte-code is either skipped entirely or converted into native CPU instructions completely before runtime.
There is a caveat though:
NGEN is intended to make the assembly execute faster by removing the JIT compilation process at runtime, but this does not always improve performance because some optimizations can be done only by a JIT compiler (i.e. if the JIT compiler knows that the code is already running with full trust, it can skip certain expensive security checks). Because of this fact, it makes sense to use NGEN only after benchmarking the application performance before and after it.
Mono C# code isn't as fast according to that link; the Mono implementation is widely known to be slower then the MS one in many areas.
Of course it can, you need 2 things to have efficient and fast code, a good Programmer and a good Compiler.
If you've got both then yes.
For example look at this
s!(?:^|\w*/|\.\./|\./)[^\s,@;:]*(?<=/)([^\s,@;:]+?)(?=[\s,@;:]|$)!$1!g;>
I tried to follow your example but there appears to be some line noise in your post ...
Is this technically a Java exploit ?
*sorry*
I normally don't like to post like this but I feel moved have to respond here; people who dismiss C# because of purported Speed/Memory issues have (imho) no idea of how to program in C# properly, or have been fed a crock by people who don't know how to program in C#.
:)
C# is like every other system out there, it has its own ways and means - it can be incredibly efficient and fast, if you use it correctly.
In fairness, even with a poorly skilled coder, a C# program can perform much better then a C++ program written with a similar amount of ineptitude; because of the way that the GC compresses your heap, causing a good chance of L2/L1 cache adjacency.
I'm trying to say that I believe it's harder to write bad C# then it is to write bad C++ etc, etc.
But ok, if you want to dismiss C# just because of standard microsoft vitriol, please - be my guest
But please don't dismiss it because you think it's slow - that's unfair and in the whole, unfounded.
If you're parsing any kind of ML with Regex, this becomes IMHO a show-stopper.
Ok ok, I know some Regex implementations implement a stack, the
I believe you should strive for legibility and clear layout when coding, and especially in these kinds scenarios - You'll thank yourself when you have to try and debug it 4 months down the line!
Possibly Track 12 on Serj Tankians 'Elect the dead' album ?
Haha! Good find :)
I knew the article was bogus, but the fact that it happened 2 years ago, really puts this to bed O_o
Actually, C# doesn't reference count at all, it 'Reference Traces' :)
Please, let me explain; it's quite sad how often people don't get this ...
.Net has its block of managed memory, called the Managed heap. It's separated into 3 'generations'. This heap has 2 areas, free space and reserved space, from top to bottom.
When you allocate and object to the heap, by using the new command (object o = new object();) there is a set of rules? that have to be enforced:
The GC manages Reference tracing, and this doesn't occur when the object goes out of scope, it actually happens when the Heap is full and you attempt to allocate a new object.
In something called 'the sweep', the GC goes through each object in the heap to see if it's reachable. To do this it starts with so-called 'roots'. It then traces to see which objects are referenced by these roots.
A root identifys a storage location, which referes to objects on the managed heap, or objects that are set to null. For example, all of an applications global and static objects are considered to be it's roots. (hence the reason that all C# apps have a static void main).
When the sweep starts, it assumes that all objects are garbage. So for each root object, it builds up a graph of the objects that root references, and marks them as being live.
However, if it finds an object that's already in the graph, it stops traversing that path. This is two (massively) increase performance by not scanning the same object twice, and more importantly, it stops you getting into an infinite loop by scanning a circular list.
The pinch is, it prevent the circumstance that you mentioned! :)
Because the strong reference to a linked circular list is gone, the circular list isn't attached to a root object, so it gets disposed. If you don't want it to get dropped, unless it theres a memory shortage, the C# GC also supports something called Weak References, but I'm not going to go into those here as it's headhurting
So once all the roots have been checked and we've got a nice graph of all the objects that are referenced by the live parts of the application somehow, the second stage of GC happens.
Any objects that haven't been touched by the walk are of course still marked as Garbage. The GC now walks up the heap linearly, looking for contigious groups of garbage which are now considered to be free space. The GC looks for the next live object and moves it to the start of this free space with a good old memcpy :)
This ofcourse invalidates all the root pointers, so the GC then updates the points in the root objects.
:)
So now, we've got rid of all the garbage and our heap is pleasantly compacted; Take that Heap Fragmentation, Kerpow!!
But, that's not all she wrote of course
Now we're free'd and compacted, the 'nextObjPtr' is moved to the top of the heap. At this point the new object creation that triggered the collection is performed and the new object appears at the top of the heap.
This is a dramatic over-simplification and I've not attempted to explain finalization or weak references, but it's still good to know this stuff, it helps us as .Net programmers to consider how to write our code properly :)
The other thing I've not explained is how the Generations work:
You make a good point, but I've just got to say that you don't need a Microsoft Language / OS / IDE to be a bad or lazy programmer. :) ... and be too proud to admit it or realise it :)
:)
In fact, you simply need to not bother trying to understand what you're doing
Look around in Googles code search, there are some shockingly bad examples of code in any language you can think of
Indeed it's a great piece of code; the only thing that puts people off is it's apparent complexity - the whitepiper that accompanies it, is a bit offputting too...
.Net Memory Profiler, from Scitech software. :)
I've had my fair share of experience with ANTs and to be honest, it's been useless in my application. We load controls dynamically in an ASP.Net environment and ANTs refuses to profile them. I've been backwards and forwards with their support team, to no avail. In fact the only thing that happened was me blocking their sales rep from emailing asking if I was prepared to make a purchase yet, when it was plainly obvious it didn't work right for us!
I've had much better experience with, and strongly recommend, the
It's saved me so much headache
My First submission, apologies for the oversight. I was just thrilled by seeing the Hacker ethos in practice and a great success from an impressive group of coders.