I have 2 versions of .NET, which is being used

[Jon Skeet [C# MVP]]

If someone is going to complain about start up time, then NGEN becomes part
of the discussion.

It becomes part of the discussion of how to make .NET apps startup
faster. It doesn't make the claim that *all* .NET apps start up as fast
as native apps true though.

See above remark. NGEN is not some 3rd party add-on for .NET that helps
overcome some inherant flaw in the design of the architecture. It is a
valid and integral part of the toolset for .NET and is applicable to all
.NET assemblies. Since all .NET assemblies can use NGEN, then my statement
holds.

"Can" isn't the same as "do", however - and even in the case when Ngen
is performed on installation, that doesn't mean that the generated code
will always be used, because hardware changes (which an app may not
know about) may invalidate the image.

Further, there are other reasons to avoid ngen in some situations. For
one thing, it *can* have a negative impact on the overall performance,
even if it improves startup time.

I just see Lloyd's comments like someone who goes to the doctor complaining
of an ailment, the doctor giving a prescription to cure the problem and the
patient just throwing the prescription away and continuing to complain about
the ailment.

You didn't just give a prescription to cure the problem, however. You
claimed that the problem didn't exist because there is a cure. That's a
big difference.

 

[Scott M.]

Jon, you seem to just want to be right no matter what the opposing opinion
is, so I'll just say that my entire point here was not to debate the merits
of NGEN. If you go back and actually read what the OP that I responded to
was, you may see that all I was trying to do was press Lloyd for specifics
because I felt that his "matter of fact" remarks that didn't provide any
background or reason to them (in fact, by his own admission - he said he had
a fuzzy memory for his "facts").

If you feel that it is not correct for me to say ".NET apps. start up as
fast as native apps. do", fine. But, I feel it is incorrect to say that
with .NET, you have:

increased memory usage
bigger download for the installation
slower start up time

This is what I was responding to.

 

[Jon Skeet [C# MVP]]

Jon, you seem to just want to be right no matter what the opposing opinion
is

Not sure where you get that from. You stated something (as if it were a
fact, given the "period" at the end of the sentence) which I disagreed
with. I don't see why I shouldn't make that disagreement public.

so I'll just say that my entire point here was not to debate the merits
of NGEN. If you go back and actually read what the OP that I responded to
was, you may see that all I was trying to do was press Lloyd for specifics
because I felt that his "matter of fact" remarks that didn't provide any
background or reason to them (in fact, by his own admission - he said he had
a fuzzy memory for his "facts").

If you feel that it is not correct for me to say ".NET apps. start up as
fast as native apps. do", fine.

And that's what I said I felt it was not correct to say, I thought.

But, I feel it is incorrect to say that with .NET, you have:
increased memory usage
bigger download for the installation
slower start up time

This is what I was responding to.

And in terms of recommending Ngen to improve start up time (at least in
many situations), and commenting on the other things, that's fine. I
just thought you took it too far by making the claim you did,
especially in the light of the very definite "This statement is
indisputable" way that the "period" implies in my view.

 

[Richard Grimes]

Now that's scary man!
(I'm also very curious now... was it some kind of not to be disclosed
answer?)

Well, it can be worked out. To work out who made the decision you just
need to look at the personel change at the time that .NET was ripped out
of Vista. As to why this happened, well, just collate the (legitimate)
gripes that people have against .NET.

(Was it some scary answer which truthfulness will diminish with each
new release/improvment of the .NET runtime?)

Steps appear to be taken, but they still have a long way to go. The list
of legitimate gripes gets shorter very slowly.

Richard

 

[Richard Grimes]

You can clearly see that the unmanaged app starts almost instantly,
whereas there is almost no difference between jitted and ngen'd
managed version. Not mentioning that there is certainly a constant
process startup time included in all the measurements, which would
make the
absolute difference in startup much more than 4x.

This is interesting, that ngened and JITted process are almost the same.
In my tests I run the method once to allow the JITting and then I
perform the testing loop (this is in the same instance of the process).
I find that for the operations I perform (floating point and integer
maths, and array manipulation) the managed code is slightly faster than
unmanaged C++ and IL generate from C# is actually faster (slightly) than
IL generated from C++/CLI.

It seems to me that too much emphasis is put on JIT compilation. If you
have a GHz processor it is capable of doing billions of instructions
before you can blink! The real constraining factor is disk access. When
you load the simplest .NET app you have many, many megabytes to load
more than a native app. The simplest native app will need kernel32.dll
and user32.dll (one and one half megabytes respectively on XPSP2) they
will use ntdll.dll (three quarters of a megabyte). Those three DLLs (and
indeed, practically all the DLLs required by the native app) are also
required by the .NET runtime, but in 2.0 mscorwks.dll is 5 meg,
mscorlib.ni.dll (ngened native image) is 11 meg! Loading 16 meg of files
from hard disk takes a lot longer than the JIT compiling of a small
method!

I just love this kind of discussion

Yes, but it's telling that Microsoft does not contribute. Also, IIRC
this type of discussion is also banned in the .NET EULA. <g>

Richard

 

[Richard Grimes]

DirectX remains DirectX, that is native code, all there for managed
development is a managed API layer, but the core remains native code.

Indeed. The first public version of Longhorn did have Avalon provided as
part of the OS, and it was used by the shell, so Avalon (and .NET) were
an integral part of the OS (which is ehere I think Lau Lei Cheong gets
his misunderstanding). However, Avalon was ripped out in later public
versions. Vista is now remarkedly non-managed, yet I keep reading stuff
saying that it is managed. For example, the promotion videos for
Microsoft Expression (Acrylic) say that Expression is used to generate
the XAML that is used to give rich graphics for Vista. As you've said,
WPF is optional. So either that promotion video is wrong (as I suspect)
or Microsoft have a XAML compiler that creates unmanaged code, which is
entirely possible because XAML is merely a markup language and the XAML
compiler is merely a code generator.

Richard

 

[Richard Grimes]

You don't need the 'oldsyntax' to compile C++/CLI that contains ATL
code, IMO Replication.dll uses ATL for easy COM interop with the DTS
core and relication package.

Yes, but my comment was a side-swipe at the natural laziness of

In my opinion there are teams in MS that won't move to C#, why should
they, C++/CLI is considered the system level language in .NET, right?

yes, but, yes, but... I do hate ported code.

Richard

 

[Willy Denoyette [MVP]]

| Willy Denoyette [MVP] wrote:
| > DirectX remains DirectX, that is native code, all there for managed
| > development is a managed API layer, but the core remains native code.
|
| Indeed. The first public version of Longhorn did have Avalon provided as
| part of the OS, and it was used by the shell, so Avalon (and .NET) were
| an integral part of the OS (which is ehere I think Lau Lei Cheong gets
| his misunderstanding). However, Avalon was ripped out in later public
| versions. Vista is now remarkedly non-managed, yet I keep reading stuff
| saying that it is managed. For example, the promotion videos for
| Microsoft Expression (Acrylic) say that Expression is used to generate
| the XAML that is used to give rich graphics for Vista. As you've said,
| WPF is optional. So either that promotion video is wrong (as I suspect)
| or Microsoft have a XAML compiler that creates unmanaged code, which is
| entirely possible because XAML is merely a markup language and the XAML
| compiler is merely a code generator.
|
| Richard
| --
| Fusion Tutorial: http://www.grimes.demon.co.uk/workshops/fusionWS.htm
| Security Tutorial:
| http://www.grimes.demon.co.uk/workshops/securityWS.htm
|
|

Richard,

The v2.0 framework is integral part of the Vista distribution (it's not an
option anymore, that is, you can't even uninstall), I would assume that
WinFX (the v3 components) will be integrated before/at RTM date. However,
that doesn't mean that it will include some managed applications or
utilities.

AFAIK "Expression" generates XAML which is markup stuff, but it doesn't
"compile" the XAML, this is something you have to do using the SDK or VS.

Willy.