Delphi and Delphi for .Net

It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton.
I would like to know is it true all .Net application is slower than Win32 native applicaiton or it is Delphi for .Net only.

Your information is great appreciated,

Inung
-1
Inung
6/21/2011 5:20:17 PM
embarcadero.delphi.non-tech 5933 articles. 1 followers. Follow

57 Replies
4658 Views

Similar Articles

[PageSpeed] 30

On 2011-06-21 18:20:17 +0100, Inung Huang said:

> It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton.
> I would like to know is it true all .Net application is slower than 
> Win32 native applicaiton or it is Delphi for .Net only.

If you are only running the code in the application once then, yes, you 
might notice a slight delay. THis is due to the JIT compiler 
transforming the IL to native code.

However, if you then time the execution of the same code without 
restarting the program, you will notice that the time take should be 
comparable to "native" code; due to the fact that, after the first run, 
..NET code *is* then as "native" as regular Delphi code.

Joanna

-- 
Joanna Carter [TeamB]
1
Joanna
6/21/2011 5:30:12 PM
Joanna Carter (TeamB) wrote:

> However, if you then time the execution of the same code without 
> restarting the program, you will notice that the time take should be 
> comparable to "native" code; due to the fact that, after the first
> run, .NET code is then as "native" as regular Delphi code.

Correction: "should be faster than Delphi code"

-- because the jitter is part of the .Net distribution and thus resides
on each computer, and is able to "customize" the compilation to
whatever CPU it finds, taking advantage of any new
features/optimizations present.

Delphi has to compile to a predetermined lowest common denominator,
since the binaries aren't altered after compilation/deployment.

That doesn't mean that Delphi exe's are slow or bad. I would to see a
number of speed improvements in the near future, but overall I'm happy
with the speed of Delphi exe's.

Loren Szendre
-1
Loren
6/21/2011 9:21:36 PM
> Correction: "should be faster than Delphi code"
> 
> -- because the jitter is part of the .Net distribution and thus resides
> on each computer, and is able to "customize" the compilation to
> whatever CPU it finds, taking advantage of any new
> features/optimizations present.

Any evidence this possibility is actually a real one? Certain basic
primitives in .NET have excellent performance because they are very well
written and are very well tested, not because of what the jitter may or may
not do. Conversely, the big weakness of .NET on the desktop (UI
performance) can't be magically fixed with the jitter.
-1
Chris
6/21/2011 9:53:15 PM
"Chris Rolliston"  wrote in message news:371446@forums.embarcadero.com... 

>>
Conversely, the big weakness of .NET on the desktop (UI
performance) can't be magically fixed with the jitter.
<<

To be honest, I've only noticed that using WPF.

SteveT
-1
Steve
6/21/2011 10:28:50 PM
Thanks for the message,
If I understand correctly, the slow is .Net, but not Delphi.
Thanks again,

Inung


> {quote:title=Loren Szendre wrote:}{quote}
> Joanna Carter (TeamB) wrote:
> 
> > However, if you then time the execution of the same code without 
> > restarting the program, you will notice that the time take should be 
> > comparable to "native" code; due to the fact that, after the first
> > run, .NET code is then as "native" as regular Delphi code.
> 
> Correction: "should be faster than Delphi code"
> 
> -- because the jitter is part of the .Net distribution and thus resides
> on each computer, and is able to "customize" the compilation to
> whatever CPU it finds, taking advantage of any new
> features/optimizations present.
> 
> Delphi has to compile to a predetermined lowest common denominator,
> since the binaries aren't altered after compilation/deployment.
> 
> That doesn't mean that Delphi exe's are slow or bad. I would to see a
> number of speed improvements in the near future, but overall I'm happy
> with the speed of Delphi exe's.
> 
> Loren Szendre
1
Inung
6/22/2011 12:51:48 AM
Hello,

Inung Huang wrote:

> If I understand correctly, the slow is .Net, but not Delphi.

no. Neither of these is slow, or fast, per se.

-- 
Moritz

"Hey, it compiles! Ship it!"
-1
Moritz
6/22/2011 1:40:18 AM
"Steve Thackery" <nobody@nowhere.com> wrote in message 
news:371460@forums.embarcadero.com...
> "Chris Rolliston"  wrote in message news:371446@forums.embarcadero.com...
>
>>>
> Conversely, the big weakness of .NET on the desktop (UI
> performance) can't be magically fixed with the jitter.
> <<
>
> To be honest, I've only noticed that using WPF.
>
> SteveT

I've rewritten a couple of my "learning" applications as WPF now and I've 
noticed a really slow start up time the first time the apps are fired up. 
If I close and restart the application again over a relatively short period 
of time the start up is much slower.  I assume that's because its been 
jitted and possibly that the necessary parts of the .Net runtime have been 
cached?  Interestingly, I haven't noticed Winforms apps being any where near 
as slow to start.

Ray Porter
-1
Lester
6/22/2011 1:45:07 AM
On 2011-06-22 02:45:07 +0100, Lester Ray Porter said:

> I've rewritten a couple of my "learning" applications as WPF now and 
> I've noticed a really slow start up time the first time the apps are 
> fired up. If I close and restart the application again over a 
> relatively short period of time the start up is much slower.  I assume 
> that's because its been jitted and possibly that the necessary parts of 
> the .Net runtime have been cached?  Interestingly, I haven't noticed 
> Winforms apps being any where near as slow to start.

Certainly, we wrote a massive .NET WinForms application and considering 
all the initialisation we do on startup, there really is no perceptible 
speed difference between the WinForms app and its predecessor Delphi 7 
version.

This assumption that .NET WinForms apps are slow is simply nothing but 
FUD, spread by people who have never done any serious .NET development, 
relying instead on misinformation found through Google.

Delphi Prism is a superb development tool and is every bit as capable 
of creating the same fast, efficient applications that Delphi can.

Joanna

-- 
Joanna Carter [TeamB]
1
Joanna
6/22/2011 9:28:48 AM
> This assumption that .NET WinForms apps are slow is simply nothing but
> FUD, spread by people who have never done any serious .NET development,
> relying instead on misinformation found through Google.

It's also furthered by Microsoft's own .Net applications, pretty much 
all their server & administration applications f.i. are pretty painful.

Visual Studio is also not exactly a showcase in UI reactivity, and just 
like Eclipse, it's saved only by very good auto-completion and 
code-completion tools, but the UI itself is a molasse.

The Delphi XE IDE UI on the other hand is rather snappy, but code 
editing support tools aren't (even though Andreas's tools help 
tremendously).

Eric
-1
Eric
6/22/2011 10:07:46 AM
> Visual Studio is also not exactly a showcase in UI reactivity, and just 
> like Eclipse, it's saved only by very good auto-completion and 
> code-completion tools, but the UI itself is a molasse.
> 

I think you need to do some reading on Confirmation Bias. I have used both Delphi and VS a lot and neither is better or worse, they both have strong and weak areas.

Craig
-1
Craig
6/22/2011 10:15:21 AM
> I think you need to do some reading on Confirmation Bias.

I think you may need to read a post before replying to it...

 > they both have strong and weak areas.

as it's just what I wrote. ;-)

Eric
-1
Eric
6/22/2011 10:18:32 AM
> {quote:title=Chris Rolliston wrote:}{quote}
> Any evidence this possibility is actually a real one? 

I would be curious to know this, myself.

--
Regards
Bruce McGee
Glooscap Software
1
Bruce
6/22/2011 10:59:14 AM
> This assumption that .NET WinForms apps are slow is simply nothing but 
> FUD, spread by people who have never done any serious .NET development, 
> relying instead on misinformation found through Google.

Pardon? It was a simple empirical observation about the .NET UIs I've come across. I've no problem with the idea an experienced WinForms programmer can make a UI as performant as anything written with MFC, the VCL or whatever other UI framework for Windows. WPF would be another matter, *depending on the hardware* - I've yet to experience an acceptably performant WPF application on my 6 month old, mid-spec notebook (e.g., the Express editions of VS 2010 are dogs on it where those of VS 2008 are very snappy
).

That said, aside from performance and flicker issues (no doubt naively written VCL UIs can flicker too), I dislike the custom/owner drawing the WinForms framework does by default - it does it in places only to still imitate the visual look of the underlying window classes.
-1
Chris
6/22/2011 12:33:51 PM
On 2011-06-22 13:33:51 +0100, Chris Rolliston said:

> Pardon? It was a simple empirical observation about the .NET UIs I've 
> come across.

Please don't get me wrong, I wasn't doubting your experience; there are 
certainly real dogs of .NET applications out there :-)

> I've no problem with the idea an experienced WinForms programmer can 
> make a UI as performant as anything written with MFC, the VCL or 
> whatever other UI framework for Windows. WPF would be another matter, 
> *depending on the hardware* - I've yet to experience an acceptably 
> performant WPF application on my 6 month old, mid-spec notebook

WPF is certainly the main beef people seem to have with .Net speed. I 
get the feeling that a lot of people have assumed that .NET was 
primarily designed for internet applications and have never really 
gotten into using it for desktop applications.

> (e.g., the Express editions of VS 2010 are dogs on it where those of VS 
> 2008 are very snappy).

Hmmm, I've yet to upgrade to VS2010 but it seems a common theme with 
IDEs that the greater the version number, the slower they get :-(

Joanna

-- 
Joanna Carter [TeamB]
-1
Joanna
6/22/2011 12:47:07 PM
> {quote:title=Chris Rolliston wrote:}{quote}
> > This assumption that .NET WinForms apps are slow is simply nothing but 
> > FUD, spread by people who have never done any serious .NET development, 
> > relying instead on misinformation found through Google.
> 
> Pardon? It was a simple empirical observation about the .NET UIs I've come across. 

This has been my experience as well.  WinForms apps appear to be more sluggish than equivalent native (VCL) or even VCL.Net apps.  We did a bunch of side by side comparisons in the .Net 2.0 timeframe.  It left me with the impression that .Net applications were better suited to things like ASP.Net (like this a lot) or other long running server applications.

The UI spoeed things had to do with WinForms using GDI+, which wasn't hardware accelerated like GDI.  I don't suppose that's changed in 4.0?

--
Regards
Bruce McGee
Glooscap Software
-1
Bruce
6/22/2011 2:14:24 PM
"Joanna Carter (TeamB)" wrote in message 
news:371604@forums.embarcadero.com...

Hi Joanna,

[..]
> WPF is certainly the main beef people seem to have with .Net speed.

you got me curious with this statement and I'd like to hear more about it if 
you have any URL worth-reading handy.
I am after "watch out for x,y,z" sort of articles.

Personally I saw some (negligeable, as you said earlier) performance 
degradation using WinForms but I was very pleased when I moved to WPF. I've 
been doing SL and WPF development for quite a while now and I've got to say 
I didn't experience any speed problems EXCEPT when binding (e.g. because of 
badly coded converters for instance) or styling was done incorrectly or is 
really (too much? <G>) flashy. Now, I also develop on good machines (my 
lesser development machine is quad-core with 8Gb) but given the amount of 
flashiness of some of our apps (compared to plain vanilla TDBGrids -alikes 
or standard, non styled WPF Grid) some hit is acceptable IMO on slower 
hardware and is to be expected (we target a lot of 1 core, 1Gb ram old 
notebooks). Unstyled and plain grids seem to work just as fast as other 
apps.

What I am trying to say is that it seems to me it's to usual 
you-gotta-know-wth-you're-doing scenario that also plagues other 
environments such as Delphi (imagine a classic TTable vs TQuery scenario 
where one is dog slow and the inexperienced might say "Delphi apps are 
slow").

Wouldn't you say or there's more to it from your experience?

Regards,
  Alessandro Federici
1
Alessandro
6/22/2011 4:15:45 PM
> The UI spoeed things had to do with WinForms using GDI+, which wasn't
> hardware accelerated like GDI.  I don't suppose that's changed in 4.0?

Vista removed hardware acceleration for the classic GDI (W7 added it back
again), so that shouldn't really have been a factor.
-1
Chris
6/22/2011 4:52:38 PM
"Joanna Carter (TeamB)" wrote in message 
news:371538@forums.embarcadero.com...

>>
Certainly, we wrote a massive .NET WinForms application and considering
all the initialisation we do on startup, there really is no perceptible
speed difference between the WinForms app and its predecessor Delphi 7
version.
<<

My experience, too, although obviously on a much more modest scale.  On the 
other hand, even VERY modest WPF apps feel sluggish.

>>
Delphi Prism is a superb development tool and is every bit as capable
of creating the same fast, efficient applications that Delphi can.
<<

Absolutely my experience, too.

SteveT
-1
Steve
6/22/2011 6:13:59 PM
"Lester Ray Porter"  wrote in message news:371486@forums.embarcadero.com...

>>
I assume that's because its been
jitted and possibly that the necessary parts of the .Net runtime have been
cached?
<<

Maybe, but I don't think so, simply because it seems to be a problem 
specific to WPF.  Presumably if it were a jitting issue you'd notice it more 
widely, don't you think?

SteveT
-1
Steve
6/22/2011 6:15:32 PM
"Eric Grange"  wrote in message news:371549@forums.embarcadero.com...

>>
Visual Studio is also not exactly a showcase in UI reactivity..... but the 
UI itself is a molasse.
<<

That's strange, I can't honestly say I've noticed that.  Mind you, I'm not a 
"power user".

SteveT
1
Steve
6/22/2011 6:16:50 PM
"Inung Huang" wrote in message news:371478@forums.embarcadero.com...

>>
If I understand correctly, the slow is .Net, but not Delphi.
<<

No, no, I think you are jumping to conclusions too soon.  There seems to be 
a modest consensus that .Net WPF applications seem to be slower to the user, 
but not everyone in this thread has found that.

There are a few people who think even WinForms .Net applications are slower, 
but that is much more contentious and certainly shouldn't be drawn as a 
conclusion.

The ".Net vs native speed" debate has been rumbling on ever since .Net was 
invented, of course, and there is still no clear consensus.  This pretty 
well proves that there can't be much in it.

That is also my experience, although I wouldn't listen to what I say.  :-)

WPF seems to be a different story, though.  I don't understand why, but I'm 
sure someone can explain.

SteveT
-1
Steve
6/22/2011 6:25:25 PM
On 2011-06-22 17:15:45 +0100, Alessandro Federici said:

> What I am trying to say is that it seems to me it's to usual 
> you-gotta-know-wth-you're-doing scenario that also plagues other 
> environments such as Delphi (imagine a classic TTable vs TQuery 
> scenario where one is dog slow and the inexperienced might say "Delphi 
> apps are slow").
> 
> Wouldn't you say or there's more to it from your experience?

I would guess that could just about sum up the situation :-)

Joanna

-- 
Joanna Carter [TeamB]
-1
Joanna
6/22/2011 6:33:47 PM
> {quote:title=Chris Rolliston wrote:}{quote}
> Vista removed hardware acceleration for the classic GDI (W7 added it back
> again), so that shouldn't really have been a factor.

Our initial testing was on XP, and I don't know anyone buying Vista now for client PCs, so yup, it's a factor.

I didn't know that hardware acceleration was removed from GDI in Vista.  I guess that's one more reason it's becoming the next Windows ME.

--
Regards
Bruce McGee
Glooscap Software
1
Bruce
6/22/2011 6:40:45 PM
Sry, for hooking in ... not directly @Alessadro

Simple comparison, Delphi out of the box fill a treeview vs. standard treeview in Winforms (2004) ... under Delphi you need the Virtual Treeview on just normal hardware these days under vista and XP to come closer to Winforms. Insert 1 Mio objects into Winforms Treeview .net 1.1 (1 sec). This is plain C under a thin layer.

Winforms .net GUI was cumbersome with GDI and GDI+ in 1.1. This is true, but solvable. Problems with XP and GDI.dll in some cases also GDI+.DLL in case of apps and GDI+ memory beyond 3 GB when memory was removed maybe from a server (this limit is set while setting up windows and not adjusted dynamic). GDI+ dll eating up to the GDI+ threshold in this case (Win XP, Win 2003 problem).

Grids under .net nothing convenient but working in Winforms cumbersome with the Grid Cell Editors.
Under WPF first no grid (.net 3.x) but it is not very complicated to have a grid implemented in WPF

..net GUI was never slow, in depth knowledge is required ... this is true but this is MS world. The advantages of WPF are far beyond from what MS commercials show ... this is another thinking - this is about freedom on the GUI. WPF has a steep learning curve ... to go beyond the first 20% and I am still learning. The moment one implements app frameworks, data driven apps ... then WPF is absolute king.

I worked one year on a silent office PC (Core I3 level little less) with never had the impression that WPF is slow ... I believe everyone his/her experience but maybe it is the graphic card ... would guess this and XP as OS. My impression was many problems went away with .net 3.5.

Greetings
Mike 

> {quote:title=Alessandro Federici wrote:}{quote}
> "Joanna Carter (TeamB)" wrote in message 
> news:371604@forums.embarcadero.com...
> 
> Hi Joanna,
> 
> [..]
> > WPF is certainly the main beef people seem to have with .Net speed.
> 
> you got me curious with this statement and I'd like to hear more about it if 
> you have any URL worth-reading handy.
> I am after "watch out for x,y,z" sort of articles.
> 
> Personally I saw some (negligeable, as you said earlier) performance 
> degradation using WinForms but I was very pleased when I moved to WPF. I've 
> been doing SL and WPF development for quite a while now and I've got to say 
> I didn't experience any speed problems EXCEPT when binding (e.g. because of 
> badly coded converters for instance) or styling was done incorrectly or is 
> really (too much? <G>) flashy. Now, I also develop on good machines (my 
> lesser development machine is quad-core with 8Gb) but given the amount of 
> flashiness of some of our apps (compared to plain vanilla TDBGrids -alikes 
> or standard, non styled WPF Grid) some hit is acceptable IMO on slower 
> hardware and is to be expected (we target a lot of 1 core, 1Gb ram old 
> notebooks). Unstyled and plain grids seem to work just as fast as other 
> apps.
> 
> What I am trying to say is that it seems to me it's to usual 
> you-gotta-know-wth-you're-doing scenario that also plagues other 
> environments such as Delphi (imagine a classic TTable vs TQuery scenario 
> where one is dog slow and the inexperienced might say "Delphi apps are 
> slow").
> 
> Wouldn't you say or there's more to it from your experience?
> 
> Regards,
>   Alessandro Federici
-1
Michael
6/22/2011 7:39:31 PM
<Michael Thuma> wrote in message news:371764@forums.embarcadero.com...

> Sry, for hooking in ... not directly @Alessadro
It's a free world :)

> .net GUI was never slow, in depth knowledge is required ... this is true 
> but this is MS world. The advantages of WPF are far beyond
> from what MS commercials show ... this is another thinking - this is about 
> freedom on the GUI. WPF has a steep learning curve ...
> to go beyond the first 20% and I am still learning. The moment one 
> implements app frameworks, data driven apps ... then WPF is
> absolute king.

I share the same feeling.
It took me a few (painful) tries to really "get it", but once you make the 
switch there's no going back (well, for me at least).

Cheers,
  Alessandro
-1
Alessandro
6/22/2011 10:19:50 PM
Alessandro Federici wrote:

>  Alessandro

Dude -- we have to do lunch!

-- 
Nick Hodges -- Product Development Manager
Gateway Ticketing Systems
http://www.gatewayticketing.com
-1
Nick
6/22/2011 10:54:52 PM
Loren Szendre wrote:

> 
> Correction: "should be faster than Delphi code"
> 
> -- because the jitter is part of the .Net distribution and thus
> resides on each computer, and is able to "customize" the compilation
> to whatever CPU it finds, taking advantage of any new
> features/optimizations present.
> 

The fact that application is compiled to the final code which includes
the newest set of microprocessor instructions does not necessary mean
that it will run fast.


Regards,
Zenon
1
Zenon
6/23/2011 4:30:31 AM
On 2011-06-23 05:30:31 +0100, Zenon Jordan said:

> The fact that application is compiled to the final code which includes
> the newest set of microprocessor instructions does not necessary mean
> that it will run fast.

But, after it is compiled, it should run, at least as fast as native 
code, because it is then native code.

Joanna

-- 
Joanna Carter [TeamB]
-1
Joanna
6/23/2011 5:47:24 AM
Alessandro,

>> WPF is certainly the main beef people seem to have with .Net speed.
> 
> you got me curious with this statement and I'd like to hear more about 
> it if you have any URL worth-reading handy.
> I am after "watch out for x,y,z" sort of articles.
> 
> Personally I saw some (negligible, as you said earlier) performance 
> degradation using WinForms but I was very pleased when I moved to WPF.

indeed. WinForms imho does sucks, not because of .NET, but because of 
it being based on GDI+ which (a) doesn't use hardware acceleration and 
(b) has the crappiest font rendering known to mankind. But i'm very 
pleased with WPF, it runs well and smooth, even in VMs. Most of Visual 
Studio 2010 itself is WPF based, for example, and it runs just as well 
(and has a lot more intriguing UI possibilities, thanx to WPF) that 
it's predecessors. Heck, and WPF fonts look better than fonts anywhere 
else in WIndows, as an added bonus.

i think most of the people here just really really love to find fault 
with .NET any way they can, to pad themselves on the back for choosing 
Delphi. As if Delphi could not stand on its own as a choice for WIn32 
app development...

marc
1
marc
6/23/2011 6:31:26 AM
> That's strange, I can't honestly say I've noticed that.  Mind you, I'm not a
> "power user".

Compared to Delphi XE, it's not as bad as with Eclipse, but when I type 
code, invoke shortcuts, etc. a bit "too fast", I find myself ahead of 
the UI and with some actions or keystrokes getting "lost" (which is 
rather aggravating as it breaks my flow).

In the Delphi XE code editor, that's doesn't happen (or at least, I'm 
not fast enough for it to happen).

Eric
-1
Eric
6/23/2011 6:45:28 AM
> 
> Certainly, we wrote a massive .NET WinForms application and
> considering all the initialisation we do on startup, there really is
> no perceptible speed difference between the WinForms app and its
> predecessor Delphi 7 version.
> 
> This assumption that .NET WinForms apps are slow is simply nothing
> but FUD, spread by people who have never done any serious .NET
> development, relying instead on misinformation found through Google.
> 
> Delphi Prism is a superb development tool and is every bit as capable 
> of creating the same fast, efficient applications that Delphi can.
> 
> Joanna


Well I have to use some .NET applications and it sometimes takes 30
seconds for even something to even show up

I am pretty sure these aren't "high quality coded" applications, but
everytime I have to launch a .NET app, I already clicked 10 times cause
I don't see anything starting up. And this is on a very recent machine
with SSD disks etc. On the other hand Paint.NET starts up rather fast


I ain't saying .NET is bad, it just depends like each language what you
need to actually build. We do have some C# webservices, but I remain
with Delphi/C++ if you want speed
1
Kristof
6/23/2011 8:47:58 AM
> Well I have to use some .NET applications and it sometimes takes 30
> seconds for even something to even show up
> 
> I am pretty sure these aren't "high quality coded" applications, but
> everytime I have to launch a .NET app, I already clicked 10 times cause
> I don't see anything starting up. And this is on a very recent machine
> with SSD disks etc. On the other hand Paint.NET starts up rather fast

in other words, some applications are bad and slow, regardless of what 
they are written in, really.
-1
marc
6/23/2011 9:10:29 AM
> {quote:title=Kristof Degros wrote:}{quote}
> Well I have to use some .NET applications and it sometimes takes 30
> seconds for even something to even show up
> 
> I am pretty sure these aren't "high quality coded" applications, but
> everytime I have to launch a .NET app, I already clicked 10 times cause
> I don't see anything starting up. And this is on a very recent machine
> with SSD disks etc. On the other hand Paint.NET starts up rather fast

That is the difference between a .NET app that have been optimized with NGEN during installation - which means no more intermediary compilation of CLI code to native code on startup, and a .NET application that has to compile it's CLI to native code every time it starts.

--
http://Lars.Fosdal.com - There are no stupid questions
http://delphi.fosdal.com - Delphi Programming
-1
Lars
6/23/2011 9:18:05 AM
On 2011-06-23 09:47:58 +0100, Kristof Degros said:

> Well I have to use some .NET applications and it sometimes takes 30
> seconds for even something to even show up
> 
> I am pretty sure these aren't "high quality coded" applications, but
> everytime I have to launch a .NET app, I already clicked 10 times cause
> I don't see anything starting up. And this is on a very recent machine
> with SSD disks etc. On the other hand Paint.NET starts up rather fast

And that is the key: startup of a poorly designed app can be slow; 
Visual Studio 2008 takes around 20 seconds on my Parallels (Windows XP) 
machine, but Developer Express DXperience Demo Center app only takes  a 
couple of seconds.

But, if you discount the startup time, with our apps, we really 
couldn't tell much difference on constructing complex forms, when 
compared with Delphi.

> I ain't saying .NET is bad, it just depends like each language what you
> need to actually build. We do have some C# webservices, but I remain
> with Delphi/C++ if you want speed

Maybe my experience of .NET is coloured by our using Developer Express 
components rather than the straight WinForms ones?

Joanna

-- 
Joanna Carter [TeamB]
-1
Joanna
6/23/2011 10:01:58 AM
> {quote:title=marc hoffman wrote:}{quote}
> i think most of the people here just really really love to find fault 
> with .NET any way they can, to pad themselves on the back for choosing 
> Delphi. As if Delphi could not stand on its own as a choice for WIn32 
> app development...

At least some of the people here find fault with .Net because there are legitimate faults to find.

These same people continue to use .Net where they think it makes sense because of the thing that don't suck.  I also like to think that at least some of these people are realistic about faults in Delphi.

--
Regards
Bruce McGee
Glooscap Software
1
Bruce
6/23/2011 10:38:37 AM
> 
> Maybe my experience of .NET is coloured by our using Developer
> Express components rather than the straight WinForms ones?
> 
> Joanna


Well DevExpress components are very good in Delphi. I can't speak for
..NET since I haven't had the chance to use them yet. But I am pretty
sure they will be of same quality as the Delphi ones. Also if you run
into an error/huge problem the support will try to fix it asap and help
you

I hope in the future they make something for cross platform Delphi also
:)
-1
Kristof
6/23/2011 11:03:01 AM
Bruce McGee wrote:

> > {quote:title=marc hoffman wrote:}{quote}
> > i think most of the people here just really really love to find
> > fault with .NET any way they can, to pad themselves on the back for
> > choosing Delphi. As if Delphi could not stand on its own as a
> > choice for WIn32 app development...
> 
> At least some of the people here find fault with .Net because there
> are legitimate faults to find.
> 
> These same people continue to use .Net where they think it makes
> sense because of the thing that don't suck.  I also like to think
> that at least some of these people are realistic about faults in
> Delphi.


Everything has it's faults and advantages/disadvantages. If I need to
create something myself, I will first look what it's going to be used
for & then decide in what to write it. And I don't mind experimenting
at all. Like one time I was working on an application which could have
limited data, but on the other hand for some customers a zillion of
records and data. They supported the standard databases. But due to the
design of the application and database some things took alot of time.
So I had some time with a database guy to experiment in using alot of
different databases. We ended up using MonetDB, which is a column based
database and for our needs it was one of the fastest possible. And yes
it had it's flaws also. But I always look at certain things like I got
these pro's and these cons are the pro's better then the cons. Then
we'll do it. If there is something else which has more pro's and less
cons, see if it doesn't require years to adapt/learn and use that
1
Kristof
6/23/2011 11:10:24 AM
> {quote:title=Kristof Degros wrote:}{quote}
> Well DevExpress components are very good in Delphi. I can't speak for
> .NET since I haven't had the chance to use them yet. But I am pretty
> sure they will be of same quality as the Delphi ones. Also if you run
> into an error/huge problem the support will try to fix it asap and help
> you

Their ASP.Net grid is quite snazzy.

--
Regards
Bruce McGee
Glooscap Software
-1
Bruce
6/23/2011 11:11:06 AM
Loren Szendre wrote:

> Joanna Carter (TeamB) wrote:
> 
> > However, if you then time the execution of the same code without 
> > restarting the program, you will notice that the time take should
> > be comparable to "native" code; due to the fact that, after the
> > first run, .NET code is then as "native" as regular Delphi code.
> 
> Correction: "should be faster than Delphi code"
> 
> -- because the jitter is part of the .Net distribution and thus
> resides on each computer, and is able to "customize" the compilation
> to whatever CPU it finds, taking advantage of any new
> features/optimizations present.

I've heard that mentioned many times before, but does it, actually, do
that, or at least do that enough? I'm not so sure anymore.
-- 
Rudy Velthuis [TeamB]        http://rvelthuis.de

"I am ready to meet my Maker. Whether my Maker is prepared for 
 the great ordeal of meeting me is another matter." 
 -- Winston Churchill.
1
Rudy
6/23/2011 12:06:15 PM
Chris Rolliston wrote:

> Conversely, the big weakness of .NET on the
> desktop (UI performance) can't be magically fixed with the jitter.

UI performance with VCL.NET was the same as native, though, IME. UI
perfoamcne of newer WinForms versions seems to have improved too.

-- 
Rudy Velthuis [TeamB]        http://rvelthuis.de

"Only one man ever understood me, and he didn't understand me."
 -- GW Hegel.
-1
Rudy
6/23/2011 12:07:29 PM
Eric Grange wrote:

> > This assumption that .NET WinForms apps are slow is simply nothing
> > but FUD, spread by people who have never done any serious .NET
> > development, relying instead on misinformation found through Google.
> 
> It's also furthered by Microsoft's own .Net applications, pretty much 
> all their server & administration applications f.i. are pretty
> painful.
> 
> Visual Studio is also not exactly a showcase in UI reactivity,

Indeed, indeed. As slow as manure rolling uphill.

-- 
Rudy Velthuis [TeamB]        http://rvelthuis.de

"Raymond's Law of Software: Given a sufficiently large number of 
 eyeballs, all bugs are shallow." -- Eric S. Raymond
-1
Rudy
6/23/2011 12:09:31 PM
Craig van Nieuwkerk wrote:

> > Visual Studio is also not exactly a showcase in UI reactivity, and
> > just like Eclipse, it's saved only by very good auto-completion and 
> > code-completion tools, but the UI itself is a molasse.
> > 
> 
> I think you need to do some reading on Confirmation Bias. I have used
> both Delphi and VS a lot and neither is better or worse, they both
> have strong and weak areas.
> Craig

I think it depends on what system they run on. On my old computer, VS
was MUCH slower than Delphi 2010 or XE. On my Mac running Win7, I
didn't try it yet, but it could be a lot faster.

-- 
Rudy Velthuis [TeamB]        http://rvelthuis.de

"A man's only as old as the woman he feels."
 -- Groucho Marx
1
Rudy
6/23/2011 12:10:46 PM
Chris Rolliston wrote:

> > The UI spoeed things had to do with WinForms using GDI+, which
> > wasn't hardware accelerated like GDI.  I don't suppose that's
> > changed in 4.0?
> 
> Vista removed hardware acceleration for the classic GDI (W7 added it
> back again), so that shouldn't really have been a factor.

Huh?

-- 
Rudy Velthuis [TeamB]        http://rvelthuis.de

"Reality is merely an illusion, albeit a very persistent one."  
 -- Albert Einstein
-1
Rudy
6/23/2011 12:25:57 PM
marc hoffman wrote:

> 
> i think most of the people here just really really love to find fault 
> with .NET any way they can,

That's so true.  Like anything else, .Net has it's fanboys and it's
haters  -- but I try hard not to get too worked up about it. ;-)

-- 
Nick Hodges -- Product Development Manager
Gateway Ticketing Systems
http://www.gatewayticketing.com
-1
Nick
6/23/2011 1:54:33 PM
On 21/06/2011 11:00 PM, Joanna Carter (TeamB) wrote:
> On 2011-06-21 18:20:17 +0100, Inung Huang said:
>
>> It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton.
>> I would like to know is it true all .Net application is slower than
>> Win32 native applicaiton or it is Delphi for .Net only.
>
> If you are only running the code in the application once then, yes, you
> might notice a slight delay. THis is due to the JIT compiler
> transforming the IL to native code.
>
I am not a pro but I have read somewhere that there are switches to 
force .NET compiler to generate final binary in advance so that the 
extra step for running JIT is not required and the app starts and runs 
like native compiled app.

MS had used this trick in their now discontinued MS Small Business 
Accounting 2006. :)
-1
Yogi
6/23/2011 2:47:14 PM
On 22/06/2011 3:37 PM, Eric Grange wrote:
>
> The Delphi XE IDE UI on the other hand is rather snappy, but code
> editing support tools aren't (even though Andreas's tools help
> tremendously).
>
I have always found that Delphi's IDE seems to take ages loading esp. 
once we have installed a few VCLs like JVCL, DevExpress, etc.

While against that VS IDE starts relatively faster. But after the IDE 
has started it seems to do loading on demand so when we click on 
something like say the Project explorer it will take some time to react.
1
Yogi
6/23/2011 2:53:25 PM
"Nick Hodges" <nick@nickhodges.com> wrote in message 
news:371805@forums.embarcadero.com...
> Dude -- we have to do lunch!

Ur right!!!
Gonna call you later
-1
Alessandro
6/23/2011 3:55:25 PM
> > Vista removed hardware acceleration for the classic GDI (W7 added it
> > back again), so that shouldn't really have been a factor.
> 
> Huh?

"In XP GDI is GPU accelerated to various degrees ... In Vista, GDI is not
GPU accelerated however the performance difference is usually not
perceptible by the user. In Windows 7, some limited GPU acceleration for
GDI was added to enable some video memory optimizations."

http://blogs.msdn.com/b/tmulcahy/archive/2009/02/11/windows-and-video-memory.aspx
-1
Chris
6/23/2011 6:24:00 PM
> I didn't know that hardware acceleration was removed from GDI in Vista.
> I guess that's one more reason it's becoming the next Windows ME.

That said, I never noticed the difference myself.
-1
Chris
6/23/2011 6:24:01 PM
> > Conversely, the big weakness of .NET on the
> > desktop (UI performance) can't be magically fixed with the jitter.
> 
> UI performance with VCL.NET was the same as native, though, IME. UI
> perfoamcne of newer WinForms versions seems to have improved too.

Hardware having caught up with something that shouldn't have been slow in
the first place...? That said, a WinForms application still has its 'marks'
where a VCL one doesn't - e.g., the WinForms Button control wrongly thinks
it can paint itself better than the underlying native widget, losing the
standard fade in/out animation in the process.
1
Chris
6/23/2011 6:41:02 PM
Joanna Carter (TeamB) wrote:

> On 2011-06-23 05:30:31 +0100, Zenon Jordan said:
> 
> > The fact that application is compiled to the final code which
> > includes the newest set of microprocessor instructions does not
> > necessary mean that it will run fast.
> 
> But, after it is compiled, it should run, at least as fast as native 
> code, because it is then native code.
> 
> Joanna


Why do you think the .Net application will run as fast as the native
application?

Is it because JIT .NET compiler emits the code  using all the newest
processor instructions?


Regards,
Zenon
-1
Zenon
6/24/2011 3:24:45 AM
> 
> Why do you think the .Net application will run as fast as the native
> application?
> 

Because they are both natively compiled applications. While both have some aspects that stronger or weaker than the other, over the long haul will be pretty similar.

Craig.
1
Craig
6/24/2011 3:49:45 AM
Bruce McGee wrote:

> or even VCL.Net apps.

Ain't that the truth! I have a VCL.NET app I use daily (my invoice
management app), and its performance is so comparable to a native VCL
app, I often forget it isn't one. :-)

-- 
Cheers,
David Clegg
dclegg@gmail.com
http://cc.embarcadero.com/author/72299
QualityCentral. The best way to bug Embarcadero about bugs.
http://qc.embarcadero.com

"Weaselling out of things is important to learn. It's what separates us
from the animals. Except the weasel." - Homer Simpson
-1
David
6/24/2011 5:41:27 AM
> {quote:title=David Clegg wrote:}{quote}
> Bruce McGee wrote:
> 
> > or even VCL.Net apps.
> 
> Ain't that the truth! I have a VCL.NET app I use daily (my invoice
> management app), and its performance is so comparable to a native VCL
> app, I often forget it isn't one. :-)

I completely understand why they made the decision to change their .Net strategy, but I really liked VCL.Net.  Sigh...

--
Regards
Bruce McGee
Glooscap Software
1
Bruce
6/24/2011 11:18:13 AM
Bruce McGee wrote:

> I completely understand why they made the decision to change their
> .Net strategy, but I really liked VCL.Net.  Sigh...

Thats only the start of the cool but now deprecated technology this app
contains (or did contain).

Its a VCL.NET ECO app which used to use BlackfishSQL as its persistence
store. It now uses the OSX version of InterBase and, thanks to ECO, the
migration to that was as simple as changing the connection string, and
writing a quick data migration utility.

-- 
Cheers,
David Clegg
dclegg@gmail.com
http://cc.embarcadero.com/author/72299
QualityCentral. The best way to bug Embarcadero about bugs.
http://qc.embarcadero.com

"I'm just trying to get into heaven. I'm not running for Jesus." -
Homer Simpson
-1
David
6/24/2011 11:42:49 AM
Chris Rolliston wrote:

> > > Vista removed hardware acceleration for the classic GDI (W7 added
> > > it back again), so that shouldn't really have been a factor.
> > 
> > Huh?
> 
> "In XP GDI is GPU accelerated to various degrees ... In Vista, GDI is
> not GPU accelerated however the performance difference is usually not
> perceptible by the user. In Windows 7, some limited GPU acceleration
> for GDI was added to enable some video memory optimizations."
> 
>
http://blogs.msdn.com/b/tmulcahy/archive/2009/02/11/windows-and-video-memory.aspx

Hmmm... Never noticed.

-- 
Rudy Velthuis

"ASCII stupid question, get a stupid ANSI !" -- unknown
-1
Rudy
6/25/2011 3:05:36 PM
HI,
Net applications use a full set of classes for everything from string handling to graphics to comms. These classes reside in the .Net Framework, and are common to all .Net languages. This set of classes generally negates the need for the Delphi run time library units such as SysUtils and FileCtrl. 


..net
1
Visual
9/2/2011 6:19:54 AM
Reply: