Programming Forums - View Single Post

lectricpharaoh · Jun 6th, 2008, 11:11 AM

To expand on what Jimbo said, generally this translation from byte code to machine code generally happens when you first run the program (or when a particular method is first called). The runtime system will cache the translated code so it doesn't need to redo its work. If a method is only called one time, or a few times, it won't contribute enough to the running time of a non-trivial program to be worth mentioning, and if it's called a lot, the overhead will be amortized over many calls. Either way, the performance hit is generally a lot less than you'd expect.

Another benefit is that when you write native code, and you want to tune it for maximum performance, you need to use optimizations specific to the processor. When writing managed code, the runtime engine can be designed so as to conditionally optimize, without the developer needing to distribute multiple versions of their program, or settle for a less-than-optimal build. In other words, sometimes it's actually advantageous to defer the native code generation.

Where managed code really gets hammered, though, is when it has to cross the managed/unmanaged boundary. If you've got a lot of this in your code, it's a good idea to minimize it. For example, rather than reading a file in small pieces, read as much as you can in each go by using larger buffers. This means less calls to the underlying OS's API, and thus less overhead from thunking down to native code. This is a primary reason that certain demanding applications tend not to be written in managed code, such as fancy 3D games (though managed support for this kind of thing is improving daily).

Back to the OP's question: you can use it for pretty much anything, with the possible exception of really low-level stuff. Even then, it's usually not impossible, just cumbersome. For regular application development, C# is a great language, and offers portability in a similar manner to Java (though perhaps not as extensive). Still, I vastly prefer C# over Java, for numerous reasons. I'd list them, but I'm tired and that's a big can of worms.

Jun 6th, 2008, 11:11 AM	#15
lectricpharaoh Caffeinated Neural Net Join Date: Jun 2005 Location: Wet west coast of Canada Posts: 1,120 Rep Power: 5	Re: im new to the language To expand on what Jimbo said, generally this translation from byte code to machine code generally happens when you first run the program (or when a particular method is first called). The runtime system will cache the translated code so it doesn't need to redo its work. If a method is only called one time, or a few times, it won't contribute enough to the running time of a non-trivial program to be worth mentioning, and if it's called a lot, the overhead will be amortized over many calls. Either way, the performance hit is generally a lot less than you'd expect. Another benefit is that when you write native code, and you want to tune it for maximum performance, you need to use optimizations specific to the processor. When writing managed code, the runtime engine can be designed so as to conditionally optimize, without the developer needing to distribute multiple versions of their program, or settle for a less-than-optimal build. In other words, sometimes it's actually advantageous to defer the native code generation. Where managed code really gets hammered, though, is when it has to cross the managed/unmanaged boundary. If you've got a lot of this in your code, it's a good idea to minimize it. For example, rather than reading a file in small pieces, read as much as you can in each go by using larger buffers. This means less calls to the underlying OS's API, and thus less overhead from thunking down to native code. This is a primary reason that certain demanding applications tend not to be written in managed code, such as fancy 3D games (though managed support for this kind of thing is improving daily). Back to the OP's question: you can use it for pretty much anything, with the possible exception of really low-level stuff. Even then, it's usually not impossible, just cumbersome. For regular application development, C# is a great language, and offers portability in a similar manner to Java (though perhaps not as extensive). Still, I vastly prefer C# over Java, for numerous reasons. I'd list them, but I'm tired and that's a big can of worms. __________________ And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot. - Vaarsuvius, Order of the Stick