Performance on .NET versus VC++ Version 6

G

Guest

Is there a performance difference if I build an application using one of the
..NET languages versus building it using VC++ version 6? Is there a
performance hit because we need to load the CLR?

Another question are all the WIN32 Api's available under .NET?

Is code written in .NET compiled or interpreted?

Thanks in advance...
 
D

David Browne

Angel said:
Is there a performance difference if I build an application using one of
the
.NET languages versus building it using VC++ version 6? Is there a
performance hit because we need to load the CLR?

Yes, lots of them, mostly small, and they go both ways.
Another question are all the WIN32 Api's available under .NET?
Yes.


Is code written in .NET compiled or interpreted?

Compiled.


But please don't use VC++ version 6. It's very old. At least uprade to the
latest VC++ compilers.
http://msdn.microsoft.com/visualc/whidbey/

David
 
L

Lloyd Dupont

Is there a performance difference if I build an application using one of
the
.NET languages versus building it using VC++ version 6? Is there a
startup time might take a little more (anything from 0.01s to 2s), the
runtime performance is similar.
in some cases .NET will even be 5% faster, in some other cases they would be
5% slower.
That's about it.
performance hit because we need to load the CLR?
not really.
Another question are all the WIN32 Api's available under .NET?
No, but you could interop it or use managed C++
also the .NET API is very vast and you could many more things in one line
which would have take 100 + and a couple of 3rd party libraries with only
win32
Is code written in .NET compiled or interpreted?
JIT, compiled on the fl just before being used.
eventually you could precompile it, but that only improve the startuptime by
a few millisecond...
Thanks in advance...
no problem
 
M

Michael Nemtsev

Hello Angel,

A> Is there a performance difference if I build an application using one
A> of the .NET languages versus building it using VC++ version 6? Is
A> there a performance hit because we need to load the CLR?

In general nope. But u need take into account that there are a lot of cases
where native code could be faster and vice versa :)
In the aspect of the cycle performing one tiny function managed code is slower
due GC, moreover it's more slower in FW 2.0 because we
can postpone memory cleaning using the Constrained Execution Regions.
But .net bring us more fast, robust and secure way to build apps

..net is not a cure-all. there are a lot of things where unmanaged code is
prevalent - low level programming, realTime apps

A> Another question are all the WIN32 Api's available under .NET?

Yep, by using interop

A> Is code written in .NET compiled or interpreted?

Compiled

VC6 is old in case if u want to get access to the latest technologies using
just C++

---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/members/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsch
 
L

Lloyd Dupont

Another question are all the WIN32 Api's available under .NET?
I'm curious as to why you said: "Yes".
I don't consider using Interop or resorting to managed C++ a classical .NET
approch...

Is there any other way I was not aware of?
 
D

David Browne

Lloyd Dupont said:
I'm curious as to why you said: "Yes".
I don't consider using Interop or resorting to managed C++ a classical
.NET approch...

Is there any other way I was not aware of?

Available. Short answer: Yes.

Long Answer: The .NET framework provides managed wrappers to most of the
functionality of the Win32 API's, and any additional Win32 API's can
easillly be accessed through .NET's Platform Invoke layer, or through
managed C++.

David
 
C

Cool Guy

Angel said:
Is there a performance difference if I build an application using one of the
.NET languages versus building it using VC++ version 6?

As for WinForms versus MFC, for example, there is no comparison IMO.
WinForms is very sluggish IME.
 
L

Lloyd Dupont

Long Answer: The .NET framework provides managed wrappers to most of the
functionality of the Win32 API's, and any additional Win32 API's can
easillly be accessed through .NET's Platform Invoke layer, or through
managed C++.
mmhh...
I see, I contest you on 2 point

1st: the API is NOT available.
you'll have to redeclare the function.
in C you could just include, let say #include<stdio.h> and that's it you
could printf()
but in C# you'll have to declare the function 1st (yourself)!
making it a tedious and error prone process.

2nd: the redeclaration is NOT always 'easy'
particularly when you have 'complex structure' with bitfield, array,
function pointer
let's take a random sample:

//==
HRESULT WINAPI ScriptShape(
HDC hdc,
SCRIPT_CACHE *psc,
const WCHAR *pwcChars,
int cChars,
int cMaxGlyphs,
SCRIPT_ANALYSIS *psa,
WORD *pwOutGlyphs,
WORD *pwLogClust,
SCRIPT_VISATTR *psva,
int *pcGlyphs
);
//==
Exporting the function itself is simple enough (though tedious) , but to
have something meaningfull you should redeclare the required struct
(SCRIPT_SHAPE, SCRIPT_ANALYSIS, SCRIPT_VISATTR) which is quite tedious.
Not too mention these are bitfield struct, although it's doable it's
rather... difficult.

It's why I decided to use Managed C++ to write my uniscribe wrapper.
Understanding Uniscribe was hard enough, I though I saved myself the
overkill process of redeclaring its many function and paramters in C#....
 
L

Lloyd Dupont

Can I use the interop in other .NET languages other than VC++ for .NET.

Absolutely.
But the great power of ManagedC++ (and the reason why I used ManagedC++ in
some project) is that you don't need to use Interop, you could call API
function staright away, just include the header and call the function.

It's great because Interop requires you to redefine the function and its
paramegter in, let's say C#.
Which could be a tedious and error prone process.

Exemple. Let say you want to use GetDeviceCaps()
It's not available in .NET.
In C# you'll have to redecalre it first (prior to use it) like that:

[DllImport("gdi32.dll")]
static extern int GetDeviceCaps(IntPtr hdc, int nIndex);

but nowehere the nIndex value are defined, so you should open the
PlatformSDK header to find the real number value and maybe declare an enum
like that:
public enum DeviceCap
{
DRIVERVERSION = 0,
TECHNOLOGY = 2,
HORZSIZE = 4,
VERTSIZE = 6,
HORZRES = 8,
VERTRES = 10,
BITSPIXEL = 12,
....

}
A tedious (and error prone) process.
Sometimes you could also find the function declared there:
http://pinvoke.net

Now, what about Managed C++ ?

Well on one hand you could PInvoke in managed C++. But frankly, that's a
waste of
1. processing power (you incure the interop cost doing that)
2. effort
because you could call the function directly as usual:
#include <windows.h>
using namespace System::Drawing;
public ref class ManagedGraphicControler
{
public:
int GetHorizontalRes(Graphics^ g)
{
HDC hdc = (HDC)(void*) g->GetHdc();
int val = GetDeviceCaps(hdc, LOGPIXELSX);
g->ReleaseHdc((IntPtr)(void*)hdc);
return val;
}
}
 
L

Lloyd Dupont

As for WinForms versus MFC, for example, there is no comparison IMO.
WinForms is very sluggish IME.
What makes you think so?

ahum.. truth to tell I never programed with MFC, so I can't compare BUT
I could compare my apps with other apps such as Word/Wordpad/other product
on my computer

And found WinForm allright, certainly better looking than some program and
as fast performing!
With the help of some 3rd parties it's even very pretty looking.
 
D

David Browne

Lloyd Dupont said:
mmhh...
I see, I contest you on 2 point

1st: the API is NOT available.
you'll have to redeclare the function.
in C you could just include, let say #include<stdio.h> and that's it you
could printf()
but in C# you'll have to declare the function 1st (yourself)!
making it a tedious and error prone process.

printf is not a Win32 API, it's a function in the C standard library.
2nd: the redeclaration is NOT always 'easy'
particularly when you have 'complex structure' with bitfield, array,
function pointer
let's take a random sample: ....
It's why I decided to use Managed C++ to write my uniscribe wrapper.
Understanding Uniscribe was hard enough, I though I saved myself the
overkill process of redeclaring its many function and paramters in C#....


Absolutely. Either a simple P/Invoke declaration exists, or you bump out to
managed C++.

David
 
C

Cool Guy

Lloyd Dupont said:
What makes you think so?

Pretty much every WinForms app I've ever run has a sluggish GUI.

For example, initial painting of controls is slow (I can generally see them
progressively being painted, from the outside to the inside usually),
controls tend to flicker, etc.
ahum.. truth to tell I never programed with MFC, so I can't compare BUT
I could compare my apps with other apps such as Word/Wordpad/other product
on my computer

GUIs of MFC apps are generally as performant as those of Word, Wordpad,
etc. for me.
 
L

Lloyd Dupont

For example, initial painting of controls is slow (I can generally see
them
progressively being painted, from the outside to the inside usually),
controls tend to flicker, etc.
mmhh...
I see this slugishness doesn't comes from .NET but from GDI+ (which is a C++
API, BTW).

I've read that GDI+ was slow in its first versions. I don't know what you
should do to have a faster version of GDI+
BUT mine performs quite well, it could be because:
- I use .NET 2.0 (updated GDI+?)
- My XP box has all the update (including GDI+ improvment?)
- I have a reasonable new video card (include GDI+ driver?)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top