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 5934 articles. 1 followers. Follow

57 Replies
1680 Views

Similar Articles

[PageSpeed] 25

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:

Similar Artilces:

converting delphi code to delphi .NET
Hi,I'm looking at converting quite a bit of old delphi code to delphi .NET .  I'm wondering can it be converted to VB.NET for certain ?  Or perhaps there are some unsupported functions etc in delphi and I should keep the code delphi ?  There are about 10,000 lines of code.   Anyone brave enough to take an estimate on how long it would take to convert 10,000 lines ?is going from delphi to delphi.NET smooth ?   Would going to another language cause complications ?Thanks! mike123   Mike123,   Sorry I can not help, however, I have the s...

Api to skydrive delphi or delphi.net
Dear Good afternoon ... Does anyone have any idea or some documentation on how to implement or delphi.net via delphi api to access skydrive files. Thank you for your help. ...

delphi Win32 using delphi .NET dll
Hi, I'm trying to use a delphi.NET dll in delphi.WIN32. I am currently using CodeGear Delphi 2007 with version2(base version) of .NET I can get the dll to import into the WIN32 application the only problem is when i include things such as: "using Classes,DateUtils, SysUtils" in the .NET dll the win32 application will instantly hang when any of the dll functions are called. Any help would be great thanks. Also I have tried this example and it also crashes for me? http://cc.embarcadero.com/Item/22688 -Braden I also found this.. "The problem is that, wehn you instal...

delphi.Net Delphi 2005 Project Upgrades?
Our company aquired the software property from another last year. Most of the projects were written in Delphi 2007. We purchased Delphi XE which gave us access to previous versions, including D 2007... all is well. However, 3 projects were written Delphi 2005 for .Net. The VM we received from this company included D2005 but it was licensed from the previous developer. I've contacted Embarcadero about obtaining a copy and or a license+registration for Delphi 2005 and was told this product is no longer available. I'm under the impression Delphi for .Net was abandoned. My qu...

Delphi.NET loading Delphi.Win32 Driver
Hi, What I'm trying to do is marshal an array of cardinal (or integer) back into managed memory from a win32 dll. I know how to pass managed memory into a win32 dll {code} var aa : array of Integer; Buffer : IntPtr; begin SetLength(aa,2); aa[0] := 1; aa[1] := 80; if not Supports(ExtractFilePath(Application.ExeName)+'Win32_Library\SDK_Driver.Win32.io', TypeOf(IMyFunctions), MyFunctions) then Exit; //loads the driver into memory. MyFunctions contains the method names found in the SDK_Driver. Buffer := Marshal.AllocHGlobal(2 * {Marshal.SystemDefaultC...

Converting Delphi for Win32 to Delphi .Net(Prism)
Hi, I am currently migrating a project from Delphi for Win32 to Delphi.net. Part of my code currently goes into a directory and pulls out a random file from this directory and loads the contents of the file for me. This code doesn't seem to work in Delphi.Net. It uses PString and a number of functions in SysUtils that don't seem to be present in Delphi.net's SysUtils file. If anyone can help me please, it would be greatly appreciated! Many thanks, Jonathan Mackey Jonathan Mackey a écrit : > I am currently migrating a project from Delphi for Win32 to &...

SEPA components for Delphi with Source Code (Delphi 5
Hi all, in the european union change next year the Bankingformat to the SEPA Format. All peoples and companies must change the bankingssoftware and the costumer data form acountnummers in the new IBAN and BIC numbers. See: http://www.arma-it.de/shop/artikelueber.php?wgruppeid=211&wgruppe_offen=211 Functions: - generate SEPA XML'S - Calc IBAN - BIC Database (DE,AT and CH) Questions: vertrieb@arma-it.de PS: Bankinssoftware for Develpoers (Germany only) http://www.arma-it.de/shop/artikelueber.php?wgruppeid=212&wgruppe_offen=212 El 26/10/13 21:38, A...

Delphi 2007 to Delphi 7
I've written a class in Delphi 2007 that is not supported in Delphi 7. What would be the best way to achive what I've done in Delphi 2007 in Delphi 7? Thanks, Tom type BondConstants = class { Bond Types } type BondType = record const TREASURY = 3; AGENCY = 0; CORP = 1; MUNI = 2; SBA = 5; MBS = 4; CMO = 6; end; { Day Count Methods } type DayCount = record const ACTUAL_360 = 2; ACTUAL_365 = 1; ACTUAL_ACTUAL = 1; d30_360 = 0; ...

Delphi 7 to Delphi XE
Have been using Delphi 7 for many moons ( have got later versions but never upgraded to ) My first problem is: Component Palette. in XE it is a small toolbar docked in top right in Delphi 7 it gives a large view of all the components. I am struggling to be able to cope/access my components.in Delphi XE. Can I make the component pallette tool bar the same size as Delphi 7, or is there a fast way to view/choose all available components in XE, that I have not spotted yet? Kind Regards, Robert. Hi, What I know is that in Delphi 2010 and XE you can choose between t...

Delphi 5 to Delphi 6 and up
Dear List, Trying to add 7Zip compression support to my delphi application. I am using the ported 7Zip sdk (see their website, they have a link). I am stumped on how to rewrite a single function: function ReverseDecode(var Models: array of SmallInt; ....): ..... where the input is mostly a fixed size array of SmallInt. This code perfectly compiles and functions in Delphi 6 and up, but in Delphi 5 I get the error: There is no overloaded version of 'ReverseDecode' that can be called with these arguments And obviously, the input (fixed) isn't the same as the param de...

Delphi XE / Delphi 2010
Hello! I noticed that Embarcadero® Delphi® 2010 Version is not on the list of products on Embarcadero page. Or is it still possible to buy it? Will RAD Studio XE compile programs written in Delphi 2010 without problems.? Thanks. Am 13.09.2010 09:04, schrieb Petra Nemec: > Will RAD Studio XE compile programs written in Delphi 2010 without problems.? As always you will probably have to recreate the projects as the import is still a bit -- special. Christian Hello! Does anybody know if it is still possible to get a Delphi2010 trial version (if yes where)? ...

Delphi 4 to Delphi 2007
Hello, I will have to port a D4 application (with source) to D2007. what kind of problem could I face ? I will have to go to customer site tommorow to analyse its source code to quote the work, what should I care of to hestimate the porting time ? Thanks John Terry wrote: > Hello, > I will have to port a D4 application (with source) to D2007. > what kind of problem could I face ? > I will have to go to customer site tommorow to analyse its source code > to quote the work, what should I care of to hestimate the porting time ? You can probably do it by just changi...

Delphi for PHP or Delphi PRISM
Hi, I have the opportunity to develop a web-based library management system. Nothing fancy, just being able to do the usual CRUD stuff for books and provide a search facility. Borrowing is to be done via an email request to the library admin who then sends out the book(s). Since both Delphi for PHP and Delphi PRISM will enable me to develop the app, which one will allow me to deliver it in less time and also increase (even how small) my marketability as a web developer? Thanks. Phillip Flores Phillip Flores wrote: > Hi, > > I have the opportunity to develop a...

Delphi 4 to Delphi 2009
Hello, Thanks to all who answered my previous question. That was a great help. And atlast our client agreed to upgrade our delphi version from 4 to Delphi 2009. *Sigh*. But before that, I need to give the estimation and cost regarding the migration to delphi 2009. Can anyone tell me is there any tool to migrate from delphi 4 to delphi 2009 or just I need to compile our Delphi 4 application in Delphi 2009. I have read from the delphi 2009 feature matrix that Delphi 1 through Delphi 2007 import is possible in delphi 2009. But i am not that sure considering the size of our application. ...

Web resources about - Delphi and Delphi for .Net - embarcadero.delphi.non-tech

Delphi - Wikipedia, the free encyclopedia
... an archaeological site and a modern town in Greece on the south-western spur of Mount Parnassus in the valley of Phocis . The site of Delphi ...

Delphi Automotive (@DelphiAuto) on Twitter
Log in Sign up You are on Twitter Mobile because you are using an old version of Internet Explorer. Learn more here Delphi Automotive @ DelphiAuto ...

Delphi Connect for Verizon on the App Store on iTunes
Get Delphi Connect for Verizon on the App Store. See screenshots and ratings, and read customer reviews.


Audi working with Delphi to develop autonomous car tech
Audi is developing an iPad-sized device that will pack all the necessary computing power for a self-driving car

US approves China company's acquisition of Delphi biz
The Committee on Foreign Investment in the United States has formally approved the acquisition of Delphi's global production of braking systems ...

Verizon And Delphi Officially Launch Vehicle Diagnostics Service - $250 For The Module, $5 A Month On ...
If you're a car nut, a paranoid parent, or a small business owner looking to do a little, uh, company vehicle economy analysis, Verizon's teamed ...

Watch out Google: Delphi gives Ars a ride in its self-driving car
The automotive components maker gave Ars a preview ride around the neighborhood. MOUNTAIN VIEW, CA—On Thursday morning I met with Delphi at its ...

The skinny on Delphi's autonomous road trip across the United States
Filed under: Green , Videos , Autonomous Last week, Delphi's autonomous car became the first to complete a coast-to-coast trip across the United ...

Delphi partners with WiTricity on automated wireless charging system
One could easily argue that parking between the white lines at any local hangout presents a challenge for some inexperienced drivers. So, why ...

Resources last updated: 12/25/2015 1:32:43 AM