memory requirement & .NET performance wonderment...

[Lloyd Dupont]

I just stumbled on a forum were people were saying they were porting old
native C++ app to winform/C#/.NET
and they experienced:
- drop in performance
- huge memory consumption.
Someone was saying this:
========
Recently I ported to C# a small transmatch cirquit design C++ application I
wrote a few years ago. The .NET port was more than 4x slower than native and
consumes up to 60MB of memory while native used no more than 5MB.
========

I found that hard to believe.
Although, honnestly, I cannot clain that I have done much real C++ work with
MFC or Win32. So I cannot realy compare objectively.
I just know that C# alway behaved well for what I need...

But anyway, I was wondering, could anyone share his experience on product
development with C# & C++ and compare the result.

Caution, I'm mainly interested in people having extensive experience in both
C++ & .NET. Not in newbied who says this new language (be it C# or C++)
sucks. But someone who has written a few real world program in both and
could compare with a wealth of performance/productivity
advice/ideas/feedback.

thanks ;-)

[Cor Ligthert [MVP]]

Lloyd,

Although you ask only people with experience in that, do I think that you
have as well to tell experience in what kind of end product.

A huge database application will give probably totally different figures
than an application completely bound to the clients screen without any extra
data influence.

C++ builds a little bit larger empty exe than C#, while VBNet is the
smallest in that. However that says in my opinion absolutely nothing.

The managed code is build as Intermediate language. That processed by the in
the Net build in CLR. This with the exception from C++ that can be *as well*
used in the classic pre Net C++ way.

Maybe you think that this will cost time and memory. The opposite is often
true, mostly it creates more efficient code and is therefore quicker and
smaller (however not forever as I tried to show in the beginning)..

I hope this gives an idea.

Cor


"Lloyd Dupont" <net.galador@ld> schreef in bericht
news:OF**************@TK2MSFTNGP09.phx.gbl...

I just stumbled on a forum were people were saying they were porting old
native C++ app to winform/C#/.NET
and they experienced:
- drop in performance
- huge memory consumption.
Someone was saying this:
========
Recently I ported to C# a small transmatch cirquit design C++ application
I wrote a few years ago. The .NET port was more than 4x slower than native
and consumes up to 60MB of memory while native used no more than 5MB.
========

I found that hard to believe.
Although, honnestly, I cannot clain that I have done much real C++ work
with MFC or Win32. So I cannot realy compare objectively.
I just know that C# alway behaved well for what I need...

But anyway, I was wondering, could anyone share his experience on product
development with C# & C++ and compare the result.

Caution, I'm mainly interested in people having extensive experience in
both C++ & .NET. Not in newbied who says this new language (be it C# or
C++) sucks. But someone who has written a few real world program in both
and could compare with a wealth of performance/productivity
advice/ideas/feedback.

thanks ;-)

[Lloyd Dupont]

> Although you ask only people with experience in that, do I think that you

have as well to tell experience in what kind of end product.
Actually I'm porting a a MacOSX application which do heavy 2D graphics GDI+.
Basically it edit/display a MindMap "a document" (a bunch of related
shapes/text/image) a bit like, uh.. like Visio?
Heaps of Graphics.
Aside from GDI+ "slowness" (I haven't noticed anything) will I be better
doing that in pure C++?

Further later I intend to write (for fun) a mini-cad application to edit /
draw dungeon-house-terrain map.
Will C++ bring me anything?
In both case I doubt so but I will be curious to hear (convincing?) pro C++
only argument. I know for sure that the nice GUI interface would be
overwhingly difficult to write in MFC (the few times I tryed in the past I
never really manage to get it)

Also I was toying with the idea to write my port of the SQLite (engine) to
..NET. Not just for the sake of it but both to learn underlying technology
and add a few feature of my own which I found lacking in the current C
implementation.
And I'm curious as to know what performance drop (informed) people will
predict me.
The managed code is build as Intermediate language. That processed by the
in the Net build in CLR. This with the exception from C++ that can be *as
well* used in the classic pre Net C++ way.

Maybe you think that this will cost time and memory. The opposite is often
true, mostly it creates more efficient code and is therefore quicker and
smaller (however not forever as I tried to show in the beginning)..

I know ;-)

[Kevin Spencer]

Hi Lloyd,

A .Net application incurs a certain amount of overhead from the platform it
runs on. Garbage Collection is an excellent way to avoid memory leaks, but
it also means that memory is not de-allocated as swiftly as in a traditional
C or C++ app. In addition, as C and C++ are basically the same language, and
a low-level language at that, any app written with C or C++ is going to
perform better than an app written using the .Net platform.

That said, the .Net platform has many methods of optimization built into it,
and a managed app can run quite fast. Specifically with regards to graphics,
I have found it necessary from time to time to use unsafe C code in my
managed applications, and when used appropriately, my apps run at a quite
acceptable pace, nearly as fast as a native C or C++ app.

I have also built apps using the Managed DirectX class libraries, and found
them to run at an excellent framerate. Again, the judicious use of unmanaged
code where appropriate is the key.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

"Lloyd Dupont" <net.galador@ld> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...

Although you ask only people with experience in that, do I think that you
have as well to tell experience in what kind of end product.

Actually I'm porting a a MacOSX application which do heavy 2D graphics
GDI+.
Basically it edit/display a MindMap "a document" (a bunch of related
shapes/text/image) a bit like, uh.. like Visio?
Heaps of Graphics.
Aside from GDI+ "slowness" (I haven't noticed anything) will I be better
doing that in pure C++?

Further later I intend to write (for fun) a mini-cad application to edit /
draw dungeon-house-terrain map.
Will C++ bring me anything?
In both case I doubt so but I will be curious to hear (convincing?) pro
C++ only argument. I know for sure that the nice GUI interface would be
overwhingly difficult to write in MFC (the few times I tryed in the past I
never really manage to get it)

Also I was toying with the idea to write my port of the SQLite (engine) to
.NET. Not just for the sake of it but both to learn underlying technology
and add a few feature of my own which I found lacking in the current C
implementation.
And I'm curious as to know what performance drop (informed) people will
predict me.

The managed code is build as Intermediate language. That processed by the
in the Net build in CLR. This with the exception from C++ that can be *as
well* used in the classic pre Net C++ way.

Maybe you think that this will cost time and memory. The opposite is
often true, mostly it creates more efficient code and is therefore
quicker and smaller (however not forever as I tried to show in the
beginning)..

I know ;-)

[Lloyd Dupont]

Mmhh... I see...
For what the 2 answers seems to confirm, while .NET use much more memory it
should provide very reasonable, if not almost similar performance.

Let's dismiss these warning reading of mine as rumor monger who didn't know
what they where talking about! ;-)

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2***************@TK2MSFTNGP09.phx.gbl...

Hi Lloyd,

A .Net application incurs a certain amount of overhead from the platform
it runs on. Garbage Collection is an excellent way to avoid memory leaks,
but it also means that memory is not de-allocated as swiftly as in a
traditional C or C++ app. In addition, as C and C++ are basically the same
language, and a low-level language at that, any app written with C or C++
is going to perform better than an app written using the .Net platform.

That said, the .Net platform has many methods of optimization built into
it, and a managed app can run quite fast. Specifically with regards to
graphics, I have found it necessary from time to time to use unsafe C code
in my managed applications, and when used appropriately, my apps run at a
quite acceptable pace, nearly as fast as a native C or C++ app.

I have also built apps using the Managed DirectX class libraries, and
found them to run at an excellent framerate. Again, the judicious use of
unmanaged code where appropriate is the key.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
A watched clock never boils.

"Lloyd Dupont" <net.galador@ld> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...

Although you ask only people with experience in that, do I think that
you have as well to tell experience in what kind of end product.

Actually I'm porting a a MacOSX application which do heavy 2D graphics
GDI+.
Basically it edit/display a MindMap "a document" (a bunch of related
shapes/text/image) a bit like, uh.. like Visio?
Heaps of Graphics.
Aside from GDI+ "slowness" (I haven't noticed anything) will I be better
doing that in pure C++?

Further later I intend to write (for fun) a mini-cad application to edit
/ draw dungeon-house-terrain map.
Will C++ bring me anything?
In both case I doubt so but I will be curious to hear (convincing?) pro
C++ only argument. I know for sure that the nice GUI interface would be
overwhingly difficult to write in MFC (the few times I tryed in the past
I never really manage to get it)

Also I was toying with the idea to write my port of the SQLite (engine)
to .NET. Not just for the sake of it but both to learn underlying
technology and add a few feature of my own which I found lacking in the
current C implementation.
And I'm curious as to know what performance drop (informed) people will
predict me.

The managed code is build as Intermediate language. That processed by
the in the Net build in CLR. This with the exception from C++ that can
be *as well* used in the classic pre Net C++ way.

Maybe you think that this will cost time and memory. The opposite is
often true, mostly it creates more efficient code and is therefore
quicker and smaller (however not forever as I tried to show in the
beginning)..

I know ;-)