Jump to content
  • Advertisement
Sign in to follow this  
serratemplar

Is C# slow(er)?

This topic is 3752 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

It makes me sad, but I am nervous posting this question - however interesting it is to me - because I don't want to be an OP in a flame war. I am not asking which is *better*, nor do I care. Furthermore, anyone asserting one over the other might get my thread shut down =( and I really want to know if anyone knows the answer to this question. I am learning C# (and frankly, I'm excited, because it eases many pains I've experienced using C and C++ all these years). As I'm reading, I've discovered that C# uses some form of garbage collection and that it compiles into some pre-compiled language which at runtime is compiled ("just-in-time" it calls it) into native machine code. C and C++ both use manual memory management (I am responsible for clean up) and compiles right to native machine code. (At least, I am certain this happens in linux/bsd environments I work on. I am reasonably certain this is the case for Windows as well.) I've grown suspicious of garbage collection since early Java wasted quite a bit of memory (allocating twice as much as was needed for a process, as I recall), and double memory is wasteful and can be slower. Having to wait for a program to compile as it runs...well, I fear that might be slower than otherwise. So here are my questions: - Does the C# garbage collection work efficiently? (are my fears here ungrounded?) - Does C# compile as it runs, or does the program compile completely and then execute? - In either case, is the wait noticeable? (I presume in the second case that it isn't, but I'm not sure.) Thank you for your time (and for not flaming) =)

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by serratemplar
- Does the C# garbage collection work efficiently? (are my fears here ungrounded?)
Yes and yes. Writing code that is efficiently garbage collected, however, requires some understanding of how the GC works and some intelligence in writing your app. (This is no different, and indeed probably substantially easier, than understanding how the native heap works and coding to avoid its pitfalls.)
Quote:
- Does C# compile as it runs, or does the program compile completely and then execute?
Both Microsoft and Mono's implementations completely JIT assemblies at load time. Note that all assemblies are delay loaded.
Quote:
- In either case, is the wait noticeable? (I presume in the second case that it isn't, but I'm not sure.)
GC delays will only be noticeable if you screwed up really badly, or are running under extremely heavy real-time constraints. Note that many of the usual tricks, like object pooling, still work if you find it necessary to go down that path.

The .NET style allocation and GC can be far, far more efficient than native allocation, but it isn't necessarily so. A lot of people write dumbass C# code and then complain about the language when it runs slowly. Some basic competence and research is required to write good code, no matter what environment.

Share this post


Link to post
Share on other sites
Quote:
Original post by serratemplar

C and C++ both use manual memory management (I am responsible for clean up) and compiles right to native machine code. (At least, I am certain this happens in linux/bsd environments I work on. I am reasonably certain this is the case for Windows as well.)

- Does the C# garbage collection work efficiently? (are my fears here ungrounded?)
- Does C# compile as it runs, or does the program compile completely and then execute?
- In either case, is the wait noticeable? (I presume in the second case that it isn't, but I'm not sure.)

Thank you for your time (and for not flaming) =)


1. yes, it is pretty fast. They been researching GC for years it has gotten a lot better.

3 No, not really.
4. You can get GCs for C++ they just don't come with the language and there are techniques such as RAII that make it almost automatic anyway.

Share this post


Link to post
Share on other sites
Quote:
Original post by serratemplar
- Does the C# garbage collection work efficiently? (are my fears here ungrounded?)
Yes. Heap allocation and deallocation are considerably cheaper than heap allocation and deallocation in C++, due to compacting collection.
Quote:
- Does C# compile as it runs, or does the program compile completely and then execute?

It can go either way. By default, the former.
Quote:
- In either case, is the wait noticeable? (I presume in the second case that it isn't, but I'm not sure.)
I've never noticed it without using tools specifically designed to notice it. I haven't done extremely allocation-intensive CLR stuff, though.

Share this post


Link to post
Share on other sites
I'll have to do some deep reading on the GC issue; off-the-cuff I'm not clear on what kind of coding practices I should be using to make sure I'm not working against the collector. Good to hear about the compilation and the speed though, over all.

Thanks guys.

Share this post


Link to post
Share on other sites
Quote:
Original post by serratemplar
1 Does the C# garbage collection work efficiently? (are my fears here ungrounded?)
2 Does C# compile as it runs, or does the program compile completely and then execute?
3 In either case, is the wait noticeable? (I presume in the second case that it isn't, but I'm not sure.)
1) The garbage collector is highly efficient, and is typically done in parallel with your actual program. The meaning of this is that the garbage collector is potentially even run on a separate core if you have a multi-core machine, and is definitely run in a separate thread [and thus in the little wait periods that exist in your program anyway]. It does take computing resources to perform, but unless you are maxing out your machine [which is very hard to do], you really shouldn't notice it if most of the garbage generated is easily collected. Benchmarks will demonstrate that most garbage generated can be trivially collected, but there exist more complicated cases that can introduce some added computation. Since it is done in the background though, this added computation typically manifests itself as a larger than expected memory footprint, rather than a sudden halt of the program [unless you start maxing system memory, in which case it stalls]. Actually, with mostly sequential or mildly threaded programs, a garbage collection system is potentially faster than the native heap allocator you see in languages like C/C++.

2) It depends on the type of program, but many programs are incrementally compiled to take advantage of techniques that may not have been obvious when the program first started, such as function inlining for functions that were linked dynamically. By the way, this JIT-style compilation is capable of quite a number of optimizations that statically compiled languages aren't. These differences are going to become more relevant in the near future as well [like dynamic function inlining, thread and function escape analysis, best case code augmentation at runtime, among MANY more]. Statically compiled languages have the advantage that they can devote a larger amount of resources to the compilation process, since us programmers are willing to wait for the hours it takes to produce release-quality assemblies that have every little air bubble squeezed out of them.

3) The wait associated with garbage collection is noticeable if you are operating at near the limit of your system resources. The wait associated with JIT compiling stuff can certainly be noticeable, and manifests itself as a delayed program start. This wait is dependent on the compiler tricks that are occurring in the background.

Since everyone else is bringing up the issue of having 'not done any allocation intensive CLR stuff', my language of choice for my *big* problems is C#. These problems are allocation heavy, and utilize no object pooling, and the CG keeps up with me. These programs also tend to re-allocate almost their entire working set every several seconds, and thus produce a truly enormous amount of garbage [FAR more than games produce]. Certainly allocation intensive, and it works fine for me.

Share this post


Link to post
Share on other sites
Quote:
Original post by serratemplar
I'll have to do some deep reading on the GC issue; off-the-cuff I'm not clear on what kind of coding practices I should be using to make sure I'm not working against the collector. Good to hear about the compilation and the speed though, over all.

Thanks guys.

This book goes into all them devlish details if you are interested?
CLR via C#, Second Edition
And yeah there are places like a managed dx game loop where it's noticeable but it looks like they finally figured it out a while back and I assume that XNA uses something similar?

My last post on render loops (hopefully)..

The most common topic on my blog returns again. This time it will be brief as all I'm going to to do now is show you the render loop the June'05 SDK will be using. A coworker in another group came up with this markedly simple, yet deceptively effective loop for that groups projects. I liked it so much, i'm sharing it with everyone else. =)

But for the most part you don't have to worry about it especially a lot less than C++ -- LOL!
Right now I'm using Allegro for my 2D games but that's because I was just taking a C++ course in college so I figured it would reinforce my C++ learning and help me pass the class and it did since I ended up getting an A ;)
But the guy that created the Allegro API I'm using in the first place has already moved on to using C# and XNA so that should tell you C# is good enough. Then again he is on the XNA team so he might be a little biased?
"Before that I worked on the Extreme G games on the Nintendo 64, and back in college I started the open source Allegro game programming library. That was my first experience of building an API for a whole community of game developers, and I found it so rewarding, that was actually one of the main things that made me want to work on the XNA Framework."



[Edited by - daviangel on June 12, 2008 8:15:55 PM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!