|
I mean that the CLR converts IL to x86 machine code at runtime.
|
|
|
|
|
That's not quite the same - an interpereted language is never compiled at any point, whereas Java and MSIL are compiled to native code at runtime, and can even be turned into a native code exe using ngen.exe .
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
I see. The processor uses esp to sense which instructions to perform from an interpreted language...
Interpreted / JIT it is about the same performance hit (in the same order of magnitude anyway)
|
|
|
|
|
No, it parses the code and calls predefined methods based on the code.
But even if it compiled it (which no doubt some interpreters do), there is a huge difference between parsing text code and reading byte code.
You can also easily create a native image from an assembly, which is just a cached native code image of the assembly, and does not need to be JITed.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
Joey Bloggs wrote:
Interpreted / JIT it is about the same performance hit
When code is JIT compiled, it will be compiled only once during the execution of the program, regardless of how many times the same code is run (in loops etc.)
In interpreted code, the interpretation process is repeated for each loop iteration.
|
|
|
|
|
I think that that would depend on how much memory is available to the VM. It might need to discard and recompile depending on a wide range of issues.
|
|
|
|
|
That's exactly right. It is not interpreted. I have read this in books
and MSDN that's why I asked before I anwsered. To be interpreted it means
that it is interpreted at runtime. Big Big difference.
Bo Hunter
|
|
|
|
|
Joey Bloggs wrote:
It might need to discard and recompile depending on a wide range of issues.
IIRC the version of .NET available on your PC does not throw out JITted code. The notion that it does happen is because of early announcements released by MS and at conferences where they were going to make 3 different JIT compilers.
That didn't actually happen in time for the framework to go live, so you have two different compilers, the one used by PCs and one used by the compact framework (which does have code-pitching).
I thought I remembered someone from MS making a comment to this end, but all I can find is this one[^].
James
"I despise the city and much prefer being where a traffic jam means a line-up at McDonald's"
Me when telling a friend why I wouldn't want to live with him
|
|
|
|
|
As I said before, if you run ngen.exe on the assemblies, they will no longer need to be JIT'ed at runtime, and therefore, will run much faster.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
|
How can I force ngen on the client?
Or you are saying I should ngen it on my machine?
What an advantage then?
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
|
igor1960 wrote:
How can I force ngen on the client?
You can run it from setup.
igor1960 wrote:
Or you are saying I should ngen it on my machine?
It has to be ngen'ed on each computer it's installed/run on.
igor1960 wrote:
What an advantage then?
Ngen speeds up start times, but it may actually slow things down overall, because it does not allow the compiler to do as many optimizations. However, it is useful where start times are crucial.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
You can run it from setup.
It has to be ngen'ed on each computer it's installed/run on.
So, I should run it during install?
And I thought: .NET is all about security!
BTW: I'm not sure you can even distribute ngen.
Ngen speeds up start times, but it may actually slow things down overall, because it does not allow the compiler to do as many optimizations. However, it is useful where start times are crucial.
About optimization: Do you know what floating point support CLR uses on each particular machine? What floating point precission to use?...
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
|
Joey Bloggs wrote:
Interpreted / JIT it is about the same performance hit (in the same order of magnitude anyway)
Certainly not! The CLR compiles to native code once and then re-uses the native code. It does not throw out any compiled code. Interpreted code is completely different from this.
Something you don't mention is that managed code in fact can be much faster:
- A managed execution environment can optimize on the specific machine you're running.
- There are JVMs that re-compiles code that is frequently run and does more heavy optimizations on that code.
- A managed execution environment can do cross-optimization over several assemblies, that weren't even known when designing the application.
The above wouldn't be possible in a non-JITted environment.
Before your next post, please spend some time learning how the CLR really works! Some good links are:
Applied Microsoft .NET Framework Programming
Writing High-Performance Managed Applications : A Primer (in the left columns you have several good articles as well)
Articles by Jeffrey Richter
MSDN Magazine
|
|
|
|
|
So much for ngen.exe and yet, how do you handle the deployment of pre-jitted apps ?
Everyone agrees that ngen.exe produces an image of your managed assembly(ies) in the GAC.
Now if you intend to deploy pre-jitted apps with your setup program, this does not work :
- the native image must be ready-to-use in the user's GAC, not in yours. So you have to prepare additional post-install steps to start ngen on HIS machine, so it does the job.
- ngen is not distributed with the .NET run-time. In other words, it is not possible to execute ngen on a client machine after a setup, since there is no such tool to play with.
- I am not sure if you are allowed to redistribute the ngen.exe tool from the .NET SDK. Quite the contrary, it is even likely that ngen.exe has a few other dependencies as well. (haven't spent time to debunk this though).
- And final point, before ngen.exe can produce and copy a native image into the user's GAC, it must be allowed to do so. On some client machines, especially those not being local admin, it's likely you won't be able to do such things.
RSS feed
|
|
|
|
|
Joey Bloggs wrote:
haven't got this far in .net yet but in java I had to implement Object Pools and an ObjectPoolManager to recycle objects. The costs in gc and performance where too high otherwise.
You're certainly right in that there's a cost involved in using heap memory - in C++, Java as well as C#. If you have objects that are expensive to create and that you frequently need to allocate and deallocate such objects, pooling is a good idea in any language. I wouldn't do it until I saw it was a bottleneck though.
|
|
|
|
|
|
I dont understand why people complain when they are lazy (iow using a GC and complaining about it). If all this .NET is so evil, then go ahead and save $100 dollars on some more hardware, and spend a few factors more developing a similar application in a non-GC enviroment.
leppie::AllocCPArticle(Generic DFA State Machine for .NET);
|
|
|
|
|
Only to defend the claims of the original poster, it's true that start time of managed apps is somewhat unusual, the memory usage too. For instance, if all windows services were managed apps, it would require much more time to reboot the machine, even if the services are supposed to be non-blocking.
It's probably harder to distribute and sell managed apps today since the end user is not yet used to it. I personally can't see my self distributing a managed app as a shareware, only to expose myself to the deployment problems, plus today's slow start time and memory consumption of managed apps.
Taking advantage of InternetExplorer to steal user's name and password.
Taking advantage of InternetExplorer to steal user's clipboard.
|
|
|
|
|
I have found that what takes alot of memory is not the classes you create, but the initial .NET CLR runtime. This means that your apps may have a large initial memory footprint, but unless you do something that normally takes a whole lot of memory, the amount of memory will not increase any faster than a C++ application beyond that.
As for the speed issues, they are because of JIT compilation. If you want to have fast startup times, run ngen.exe on each of the assemblies in your application. This creates a native image of your assembly, so it does not need to be compiled at runtime. Nish and Rama Krishna did a study on the speed of ngen'ed and non-ngen'ed C#, VB.NET, VB, ngen'ed MC++, non-ngen'ed MC++, mixed C++, etc., and they found that C# is not alot slower than C++ once it has been ngen'ed, because there is no longer the overhead of JIT compilation.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
If you display forms using Form.ShowDialog() (shows a modal dialog), you must call Form.Dispose() when you're finished with it. The documentation for Form.ShowDialog() even states this.
Managed application are often bigger memory hogs than their Win32 counterparts, but they can also be faster when managed correctly by your code. Keep in mind that most "windows crashes" are usually actually applications' faults (or users - more often users' faults!). Even though the GC will cleanup memory eventually, you must make sure that all references to an object are disposed. After calling Form.ShowDialog, the form is not disposed until you do so manually. When you start throwing controls and strings in multiple collections, you must make sure than no collections still hold a reference to them. If so, the object still exists on the heap and the GC won't clean it up.
The reason it is sometimes faster even though it is JIT'd (not interpreted like someone said before - I too get deep into the internals of the CLR and IL) is because of improvements in heap and general memory management - that doesn't necessarily mean smaller memory requirements, unfortunately.
I think another reason for large sizes is something I suffer from a lot - overly large assemblies. For instance, in a signed XML app I wrote, I'm forced to use the Microsoft.Web.Services assembly for one class because the System.Cryptography equivalent (using enveloped signatures in this example) doesn't work (at least, not yet). So, the whole Microsoft.Web.Services assembly must be loaded into memory (at least, unlike older implementations of Java, the whole thing isn't JIT'd - just the class I need). This happens quite a bit from what I see. Sometimes making things too easy isn't necessarily a good idea (read "good developers loosing jobs to crappy drag-n-drop VB code monkeys").
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Hi everybody.
I posted a question here yesterday regarding the intricacies of the ECMA CLI standard, and how to determine the number of bytes you should read for a particular metadata table.
Zoiks, sounds exciting eh? You bet. If anyone has any interest in reading .NET dlls,or any knowledge of Partition 2 of the CLI standards, please check out my question as you may be able to help.
To my shame, I have accidentally cross posted this on the C# board - what a numpty!
Much appreciated, thanks.
Jason King
jason.king@profox.co.uk
Feel the love at www.profox.co.uk
|
|
|
|
|
|
Thanks Leppie. I will take a look. I remember talking to you earlier this year / last year about graphics libraries and the like. Did you get sorted with what you wanted? Maybe we were just nattering and you didn't need anything at all....
Jason King
jason.king@profox.co.uk
Feel the love at www.profox.co.uk
|
|
|
|
|
Hi,
I developed a .net control in XP with .NET framework 1.0.
It works fine when used in XP or Windows 2000, but when I use the application in NT 4.0 service pack 6 with .NET 1.0, it simply fails to load ... i get the message "Unable to load file ‘MyControl.SplitButton’"
MyControl.SplitButton is my assembly - MyControl.SplitButton.dll.
Leave alone not working, NT simply fails to even load the asembly (as per the above message).
Do you think I will need to rebuild the assembly in NT 4.0 (...Windows is really painfull...)
Any thoughts please....
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
