Delphi Handbooks Collection


Delphi XE Handbook


Delphi 2010 Handbook


November 5, 2008

Delphi Native Code: Fast or Reliable?

Delphi for Win32 is a tool focused on native code. Delphi compiled programs are fast... but does this really matter? In my view, reliability and stability are more important.

Delphi for Win32 is a tool focused on native code. Delphi compiled programs are fast... but does this really matter? There has been some debate over the last month, with CodeGear Product Manager Michael Swindell pushing Delphi for its fast compiled code, and Hadi Hariri and other bloggers disputing this idea. Truly, Microsoft .NET is not really slower than Delphi compiled code. So why does Delphi and its "traditional" Win32 support still matter, and matter quite a lot?

In my view, reliability and stability are key factors, more then speed. The fact is you can be sure your Delphi application of 5 years ago can be easily moved to Vista and Unicode support, without a total rewrite as in case of a VB application moving to VB.NET. Similarly, you might not be using the latest, smartest, and coolest technology if you create a Delphi database application today, but you can be pretty sure it will keep running for a few years. This means you can embark on a long term project with limited fears (now that Delphi has left Borland for a more solid company).

What about a .NET client/server application written today? Will you write traditional ADO.NET code, with no coolness factor? Will you use LINQ to SQL, which is being deprecated today? Will you use the Entity Framework, which looks great but is a brand new and far from stable technology? Will you wait for Oslo? And what about the user interface in case you don't care about the Internet? Will you use WinForms or the totally incompatible WPF? What will be around and kicking in five years time? That's very hard to know.

The same dilemma was there in the Java world in the early years, but after some time things got stable. Yes, they are slower to move than on the .NET platforms (or so it seems to me) but large corporations with long terms investments need stable technology, not ever-evolving-forever-beta cool architectures.

I keep thinking that if you can keep evolving a platform, adding new cool features, without disrupting existing investments you are doing your users base a huge favor.... Or am i getting too old to understand?

posted by marcocantu @ 7:23PM | 39 Comments [0 Pending]




 

39 Comments

Delphi Native Code Fast or Reliable?  

One thing I don't see mentioned often enough is how 
native code apps generally load faster than .NET apps 
(especially when the .NET runtime isn't already in 
memory).  An app that takes longer to load will be 
seen as slower than the competition, even if it's 
faster in all other aspects.
Comment by Nick Bradbury [http://nick.typepad.com/] on November 5, 20:40

Re: Native code  

Source code compatibility is definitely an issue. 
Borland/CodeGear have proven to provide backwards 
compatibility for many, many years, creating solid 
products. Microsoft, on the other hand, has a track 
record of creating backwards incompatibilities, and if 
their earnings and backwards compatibility should 
conflict in the future, they will always go for the 
earnings. There are still lots of VB 6.0 developers 
out there, because those old apps need to continue, 
but Microsoft won't help them.

I'm a leader of a development team where we restrict 
the use of certain language features in order to 
ensure compatibility into the future and code 
simplicity. This saves money and secures our 
investments. I would not allow LINQ unless I see a 
business case that says that we make more money by 
allowing it, than if we didn't. Already, we don't 
allow pointer operations except in special units that 
are optimized for performance.

I can read between the lines, that you guys are 
thinking about the future roadmap. Don't let Kylix 
make you afraid of supporting other platforms. I was 
one of the Kylix customers, and I immediately found 
the huge flaw in Kylix: It was sold as being "for 
Linux", but it was really for "Intel i386 Linux with 
specific libraries". Since CLX was very sparse, Kylix 
mostly made sense for industrial applications, and 
that required support for other CPU architectures, 
which was not possible and not roadmapped.

You would have had more success with a Kylix that 
compiled for mono, or a Delphi that generated Win32 
exe files that were guaranteed to work with Wine. It 
would give you all the VCL 3rd party components, and 
still be Linux compatible. I still test our 
applications with Wine from time to time, just to make 
sure that they could be deployed on a virtualized 
Linux/Wine, if needed.

That said, what advantages does Delphi/Win32 give? I 
see several: Simple deployment, exe files run directly 
off a document folder, even on machine on which you 
have no administrative rights. Performance and memory 
usage: I don't know why .net GUI apps tend to be slow 
and memory consuming - but our apps are definitely 
fast and memory tight and always act in a predictable 
manner.

The main disadvantage is memory allocation. This can 
be solved by proper code style guides, but it would be 
cool to see some kind of deterministic and automatic 
object deallocation. Don't use a garbage collector - 
it may perform better in average, but it performs in a 
less predictable way. And the question is, does the 
increased speed of the garbage collector system really 
outweigh the disadvantages of using more RAM? The 
multithreading advantages of garbage collection memory 
management can be solved in much better ways in the 
language itself. Garbage collection is a temporary 
good solution to multithreading memory performance, 
but when the number of cores goes up a lot, 
deterministic memory management will be necessary. I'm 
fully convinced that we will see more NUMA-like 
hardware in the future, where there is a thread/memory 
relation which determines performance, and where the 
language needs to help the programmer specify which 
threads use what memory, before it is being used. Just 
imagine 1000 mergesort threads on a 1000-core NUMA 
machine, that need to merge lists. The read/only data 
can be copied from core to core, but the resulting 
lists from each thread definitely need to be stored in 
the RAM associated with the thread's CPU, until it is 
ready to be copied to the next CPU. We need a language 
that makes this easy. Why? Because Delphi will still 
be around in 25 years.
Comment by Lars D [http://compaspascal.blogspot.com/] on November 5, 20:52

Delphi Native Code Fast or Reliable?  

That basically summarizes the problem of .NET. After 3
weeks of vacation you can't be sure that the framework
you were using is still supported, has not been
deprecated or replaced with something else.
Less is more I think.
Comment by Olaf Monien [http://www.monien.net/blog] on November 5, 21:58

Delphi Native Code Fast or Reliable?  

I think this is a huge chance for Delphi.

Lots of developers, including myself, are sick and 
tired of chasing the latest greatest coming out of 
redmond. 

C# has become incredibly complex in a very short time 
and there's no sign that this madness will stop any 
time soon. 

Delphi on the other hand is pure and simple. 
Beautiful. However, its major drawback is its narrow 
platform focus. 

I wish Codegear would focus more on bringing Delphi to 
more platforms instead of messing around with crappy 
PHP and Ruby- IDEs.
Comment by fritz on November 5, 23:07

Delphi Native Code Fast or Reliable?  

I'm in strong agreement with you here Marco, the speed
of the code is not the most important thing.  I work
on a project that was originally written in Delphi 1
and has been under continuous development since then.
 It has been compiled with every version of Delphi
(except 8 and 2005) and run on everything from Win95
to Vista.  That is to say, portability between
versions is highly important to me.

Certainly when running on Win95 boxes ("fast" 486s and
Pentiums) the speed of the code mattered greatly, and
was a concern for us, however, the cheapest computer
you can buy now runs our software great.

If it had been written in VB, how many times would it
have needed to be rewritten from scratch?  Or would I
still be stuck in VB6.

I've just spoken to someone migrating 1.3 million
lines of VB6 code to Delphi 2009. "Against much VB
patriotic zealots advice, I am pleased I have made the
switch".  He sounds pretty happy.

Anyway, I'm starting to rant ;-)
Alister
Comment by Alister Christie [http://codegearguru.com] on November 5, 23:21

Delphi Native Code Fast or Reliable?  

Totally aggree!

This is the main reason I try to avoid .NET stuff.
I've done a lot of VB back in the days of version
3,4,5 and 6, before I jumped in to Delphi. One of the
main reasons for the move was that there was always a
new and improved technology that you seem forced to adopt.

So far my Delphi code has been stable and it has
compiled across several versions without a hitch(As
long as my third party components are up to date). And
it is still a very much productive tool.
Comment by Mane [http://www.open-consult.com/] on November 5, 23:47

Delphi Native Code Fast or Reliable?  

I think that, programmers have their own fashion and
they try to follow it, not try to make existing
technologies better. Especially if that fashion comes
from the big boss. "Hey look at that what a great idea
that is the future!". In these days whatever MS makes,
it becomes WOW. 

When the .Net first introduced it was lots of missing
pieces if you compare with VCL. But third party
vendors had closed that missing parts.


Many software houses migrate their solid, stable
projects made with Delphi to .Net. Why a person makes
such a think? I can only explain that with "Following
the Fashion" to my self.

Market needs new ideas, products, ... for to be alive,
for to make money.
Comment by Namık Kemal Karasu on November 6, 00:32

Delphi Native Code Fast or Reliable?  

Dear Marco,

In my opinion, Microsoft .NET 3.5 is an stable and 
robust application platform. Although there are bugs 
but I prefer .NET to Win32. Why? A very simplified 
example: you can use Microsoft Enterprise Library, 
when you want to implement a composite/complex 
caching mechanism:

Microsoft Enterprise Library
http://msdn.microsoft.com/en-us/library/cc467894.aspx

Or there are WPF data bindings too (the next 
generation of data controlled applications):
http://msdn.microsoft.com/en-us/library/ms752347.aspx

Microsoft Dynamics (CRM - Business Applications)
http://www.microsoft.com/dynamics/default.mspx

Azure Services Platform (ASP)
http://www.azure.com

Perhaps, it is time to change. :)

Dear my friends, Delphi Prism is the future.
Comment by daywalker [http://devportal.hu] on November 6, 01:29

Pascal is still faster.  

 http://shootout.alioth.debian.org/debian/
benchmark.php?
test=all&lang=all&calc=calculate&xfullcpu=1&xmem=1&xloc=1&binarytrees=1&chameneosredux=1&fannkuch=1&fasta=1&knucleotide=1&mandelbrot=1&meteor=1&nbody=1&nsieve=1&nsievebits=1&partialsums=1&pidigits=1&recursive=1&regexdna=1&revcomp=1&spectralnorm=1&hello=1&sumcol=1&threadring=1
Comment by Anonymous [] on November 6, 10:38

Delphi Native Code Fast or Reliable?  

There are several things that can make programmers use 
a certain language. Hype/New features/Going with the 
flow is the most well known. Sticking with what works 
is another one. Microsoft is about the first, CodeGear 
is about the last, and that's why CodeGear's customers 
are so loyal. Many of us know several tools and 
languages, but when we need to get something done, we 
can do it with Delphi/Win32.

It's the small things that make Delphi cool. 
AnsiString was faster than the Microsoft compatible 
WideString. The support of Variant in a compiled 
language was extremely cool - a real feature enabler.

What Delphi needs, is to make things possible, without 
getting bloated, and without blocking the future. Many 
Microsoft libraries make things bloated or 
complicated. Whenever CodeGear can make Delphi do one 
of these simpler, Delphi gets an advantage. For 
instance, VCL instead of MFC, Firebird instead of 
MSSQL, MIDAS/XML instead of DCOM, Indy instead of 
Win32 API, IBX instead of ODBC/ADO etc.
Comment by Lars D [http://compaspascal.blogspot.com] on November 6, 10:59

Delphi Native Code Fast or Reliable?  

Does speed matter? Sometimes, yes. Does scalability 
matter? Sometimes yes. It depends on what kind of 
application one is developing.
Unluckily the Delphi compiler didn't keep pace with 
new CPU features - hope the next 64 bit compiler will 
fill the gap - and will improve somewhat the 32 bit 
compiler too (although sometimes I am afraid we will 
have the only 80386-64 compiler on the market <g>).
A better memory manager had to be borrowed from a 
contest set up by users - the same happened for many 
RTL functions.
Does using a native compiler make sense when it 
outputs old 386 code, its memory manager was designed 
in times of old, and its RTL is not performant and 
relatively poor, when p-code can be precompiled or 
jitted to take advantage of latest CPUs, garbage 
collectors improve, and good frameworks are developed?
Native code makes really sense when working on 
application with special needs - speed, memory, 
footprint, low level data access and system 
integration. But it has to fully take advantage of 
them.
I am happy if I can compile ten years old source 
code, less happy if I get ten years old compiled code.
Comment by Luigi D. Sandon on November 6, 12:18

Delphi Native Code Fast or Reliable?  

With the support of oxigene the .net dream from 
codegear is closed. We have now a real alternative 
for .net programming a la microsoft manner.

Linux servers are knocking the door of enterprises 
now, and we can be there without a big economic 
effort. The linux desktop part can wait for future 
versions.

Now we need to really slowly rethink the "real" 
delphi roadmap to make it a "fashionless" native 
multiplatform environment.
Comment by Francisco Ruiz on November 6, 12:22

Delphi Native Code Fast or Reliable?  

I totally disagree. Even though I'm an avid win32
Delphi programmer, the future in all topics is
virtualization - regardless whether it is OS,
Applications or programming code. Why?

Well, abstractive layers (yes, I disagree with the
onion thing) is something you use in Programming too,
why not in the resulting Programming Code as well?
Advantages: Portability. Will my app run on Windows 7
(or how about MacOs or something like Android)? On a
virtual code base: yes. Native code? Maybe - what
happens if my OS turns into a 64 Bit System only
without 32 Bit support (which my "old" app is in)?
With "virtual Code" this is no problem.
of course there are things to consider like
visualization problems (WPF Problems, etc, take a look
at how Java solved this).
Native code is needed for slow and old devices, sure.
but for example take a look a the mobile phone cpu's,
how the increased processor speed in the last years.
ok battery life had to be optimized as well as a
sidedraw, but this is a general problem.
Virtual Code has one more big advantage: No one is
caring about the Language which created the code. Is a
Delphi programmer compared to a C++ only a second
class programmer? With virtual code: No. Wouldn't it
be nice to use Delphi for all OS and devices (like
iPhone)? If virtualized code overrides the generic
aspect, this is possible. I love the future.

Generally spoken, my opinion is:
The future (not today) is virtualization in every
aspect. Including program code.
Comment by Dennis S on November 6, 12:49

Delphi Native Code Fast or Reliable?  

@Dennis S - I don't know if you remember the hoopla
surrounding 4GLs, Prolog, etc. This topic comes up at
least once per programmer generation. And it doesn't
work, not because of speed, but because in the end,
when the customer says he wants his logo three pixels
further in, you gotta have a way to do that.
Virtualisation creates layers of abstraction that you
have to fully understand before you can do anything
non-trivial.

After 5 years of C# programming, I still find I have
better control of the end result using VCL forms than
using .NET, also better control over memory allocation
and release, graphics, etc.

.NET is fine for database front ends (yet even then,
in my experience, not always...), but for an
industrial grade application, you need the granularity
native code gives you.

Speed? Startup speed is what makes the first
impression. I hate how .NET apps wobble into life. We
had to break out some graphic stuff to C++ code for
speed and ran into distribution difficulties. Delphi
would have done it in the same exe. Indeed, one form
that selects a directory is now a Delphi .dll which I
quickly knocked up after none of the experts could do
what the customer needed using .NET.

Support for newer processors? What for? (see above)
Doing so merely limits the supported hardware base,
which may be uncool, but I need to pay the bills.

I even ran into the trap years ago of using supplied
features like Actions, and various 3rd party tools
that shipped with Delphi back then. Bad mistake. Never
again. In the long term, for serious, long-life
applications, building your own is the best solution.
It does exactly what you need, only what you need, and
you know how it works.

The only thing I wish for is some way to reduce exe
size in Delphi. The identical app just gets bigger
with each Delphi version.
Comment by Ken Knopfli on November 6, 16:31

Delphi Native Code Fast or Reliable?  

Yes, you're old! :-) But so am I and quite a few other 
Delphi programmers. It just seems as if every new 
programmer just skips Pascal as an alternative 
language. C# tends to become what Pascal used to be 
about 20 years ago. I still remember building 
applications in Turbo Pascal 3.0 om my 8086 XT 
computer with 640 KB ram and a hard disk of 20 
megabytes.
Yes, back then native code was really important. 
System resources were low and slow so as a programmer 
you had to do anything you could to gain some 
performance.
Nowadays, we have plenty of resources. Memory gets 
measures in gigabytes and terabytes nowadays. I 
sometimes wonder if anyone can still remember the 
kilobyte and I feel old because I can. When you have 
lots of resources then you can waste some to make 
development easier. No longer do you need the fastest 
algorithm. Nowadays you need those that are easier to 
understand and implement. A simple thing like a hash 
table is just a standard part of many development 
systems but there was a time when I had to write my 
own. And while my own implementation would be much 
faster than those current implementations, I still 
can't fight at the ease of those modern ones.

I feel as if I've build some fast boats that can 
travel around the world in a few days, yet now we have 
these huge cruise ships that are bulky and slow but 
everyone prefers them because they're way more 
comfortable...
Comment by Workshop Alex on November 6, 16:33

Virtualization  

Virtualization and sandboxing also means that it 
doesn't matter, whether your app is .net, java or 
win32/win64 based.
Comment by Lars D [http://compaspascal.blogspot.com/] on November 6, 16:36

Delphi Native Code Fast or Reliable?  

Oracle's Larry Ellison already said (talking about
cloud computing but can be applied in general)

"... The computer industry is the only industry that
is more fashion-driven than women's fashion. Maybe I'm
an idiot, but I have no idea what anyone is talking
about. What is it? It's complete gibberish. It's
insane. When is this idiocy going to stop?"

And I'm sure he must know ...

Daniel
Comment by Daniel Luyo on November 6, 16:46

Delphi Native Code Fast or Reliable?  

I surely do not think that .net usage is for db front
ends only, for god shake!
We build any kind of app here (and millions other are
doing this) without problems and with very good results.

Also, M$ has done a quite nice work in 3.5 SP1
regarding app startup speed. It really makes a
difference now.

As for Delphi, i think that "Reliable" is it's best
bet. And this because with these processors nowadays
and with .net speed at a very good level, it's
(Delphi's) always admirable speed, is now not relevant
any more.
Comment by king kikapu on November 6, 18:21

Delphi Native Code Fast or Reliable?  

"Virtualization" is another buzzword of today - I see 
lots of people wasting resources setting up VMs for 
everything while they often could do without - just 
setting things up as they should have been in the 
first place.

And don't forget the Law of Software Inflation: 
software expands to fill the available hardware. No 
matter how processor speed and memory increases, 
software needs will increase more.

"Virtual Code has one more big advantage: No one is
caring about the Language which created the code." 
Well, that's true for compiled code too. Who cares 
about what language your .exe was created with??? At 
least you don't see everytime you get a new 
application "sorry, this application requires 
JRE/.NET framework x.y.z, install it to run this 
application". Or do you believe that each language 
compiler would produce the same "virtual code"? And 
do you believe all WMs will be "created equal"? Is a 
Mono VM on par with a MS Windows VM? Again, the 
problem just shifts...

"Wouldn't it be nice to use Delphi for all OS and 
devices (like iPhone)?"
Yes, but each OS and device has its own GUI, rules, 
design guidelines and platform specific features - 
does one really believe he can use the same code for 
a Windows and iPhone application? And if he could the 
problem is not how instruction are translated into 
machine executable code, be it a compiler before or a 
VM/jit later, the problem is how to develop a *real* 
cross-platformm framework - those existing now or 
makes your application look alien on each platform, 
or make your application ugly on each platform.

"Will my app run on Windows 7 (or how about MacOs or 
something like Android)? On a virtual code base: yes. 
Native code? Maybe"
Are you sure? What if you have an application 
requiring an old WM like JRE 1.3 or .NET 1.0 and your 
brand new OS no longer supports them? 

"but for example take a look a the mobile phone cpu's"
Take a look at mobile phone OSes: Windows Mobile 6.1 
is slow even on latest CPUs, especially on devices 
with high resolution screens, "software expands...."
Comment by Luigi D. Sandon on November 6, 19:50

Delphi Native Code Fast or Reliable?  

Hi Marco, 

I was going to follow-up here but it turned out quite
long. So I've followed up on my blog.
Comment by Hadi Hariri [http://www.hadihariri.com/blogengine/post/2008/11/06/Delphi-Native-Reliable-all-combined-into-one.aspx] on November 6, 20:32

Delphi Native Code Fast or Reliable?  

1. Microsoft will never port it's Office suite to .NET

2. Microsoft will never release a Windows version on
which it's Office suite will not run.
Comment by Ken Knopfli on November 7, 12:12

Delphi Native Code Fast or Reliable?  

Any sample of relevant applications made with .net?

In the native world I can count most everything you 
are using including the visual studio and the java 
virtual machine.
Comment by Francis on November 7, 13:41

Delphi Native Code Fast or Reliable?  

@Francis

Not entirely true: Visual Studio 2005 had 7.5 million
lines of C# code...

http://blogs.msdn.com/danielfe/archive/2005/12/16/504847.aspx
Comment by king kikapu on November 7, 17:02

Delphi Native Code Fast or Reliable?  

@King Kikapu

It's true, but which support the entire house isn't 
c#. in words of Michael Swindell:
'Despite reports to the contrary, native code 
remains the core foundation of application 
development'
Comment by Francis on November 7, 18:43

Delphi Native Code Fast or Reliable?  

@Ken
"Microsoft will never port it's Office suite to .NET"

Why not? It may not happen today or tomorrow, but I
think this will be done some day. 

@Luigi
"Who cares about what language your .exe was created
with???"
The ones who asks me on porting it to a unix system
(not running wine). With native code the compiler has
to be unix aware (hooray dead kylix) or there has just
to be a compatible environment (hooray mono) and my
delphi app will run on linux and macOs.

Currently I'm still using native Win32-Code (hello
64Bit-Delphi?) but thinking about moving to the future
some day (.netish), when "fast" and "reliable" applies
to those code outputs as well.
Comment by Dennis S on November 7, 19:21

Delphi Native Code Fast or Reliable?  

Native or managed? Here is my answer:

Microsoft Singularity (the first managed OS "core")

http://channel9.msdn.com/shows/Going+Deep/Singularity-
A-research-OS-written-in-C/

http://en.wikipedia.org/wiki/Singularity_
(operating_system)

The future is beautiful.
Comment by daywalker [http://devportal.hu] on November 7, 22:28

Delphi Native Code Fast or Reliable?  

 @Francis,

This might come as a shock, but below .NET, Java and
even Delphi is ASM. Should we all just use ASM?
Comment by Hadi Hariri [http://hadihariri.com] on November 7, 22:53

Delphi Native Code Fast or Reliable?  

@Francis:

Do you see that Swindell's opinion is fulfilled in
reality ?? Because the only thing i see, is that M$ is
investing on .net more and more.
Comment by king kikapu on November 7, 23:42

Delphi Native Code Fast or Reliable?  

@daywalker
Here you have an alternative to microsoft singularity.
http://gocosmos.org/index.es.aspx, it's cosmos a 
really open source c# from Kudzu (father of indy and 
winshoes), in an interview to zdnet you can read :
Kudzu: Singularity actually has a fair bit of C or C++ 
down in the core. Cosmos is 100% C#. The only assembly 
is emitted by our compiler.

@Hadi (about asm)
Of course not Hadi. What's a nightmare.

OK c#.net is a really fantastic work plenty of 
functionality. But if you want to use it, here is 
prism. (I also will use it for some works). But delphi 
for win32 need to go in his own way and don't play in  
java and .net arena.
Comment by Francis on November 8, 23:44

I need all  

I need Fast, Reliable, Maintainable and Portable apps.

The problems i have seen with .Net as  compared to
delphi are. 

1. Slow load times.
2. Deployment Headaches like
    a. not a single exe any more.
    b. Suddenly your app stops working. Solution:
       Just reinstall .Net framework and its
       gone. simple.
3. Slow UI.
4. More memory usage.

on the contrary i like

1. asp.net
2. I can program devices. (Although when i tried 5
years back the resulting app was too slow to be useful
for my clients.)

Om sure there must be more to add here.

Regards
Comment by bravo on November 9, 17:05

Delphi Native Code Fast or Reliable?  

@Dennis: "With native code the compiler has
to be unix aware (hooray dead kylix) or there has just
to be a compatible environment (hooray mono) and my
delphi app will run on linux and macOs."
Again, it's just a matter where your code gets 
transformed into machine code. It's not a matter if 
executable is a native code image or a p-code image. 
There's plenty of C/C++ compiled code that run on 
Unix, Mac and Windows machines. The problem is the 
lack of a Delphi compiler/framework for non-windows 
platforms, not a issue of native code itself.
As much as Mono framework lacks several .NET features 
available on Windows - there's not assurance your 
application will run on Mono unless limit yourself to 
Mono on both platforms.
The very fact that Kylix went nowhere means that many 
Delphi developers dream a multiplatform tool but very 
few actually tried. I guess many now talks about 
going everywhere with Mono just to stick to 
Windows.NET - it's just the "feel good factor".
Comment by Luig D. Sandon on November 9, 20:38

Delphi Native Code Fast or Reliable?  

Did you see trolltech QT? one framework can create
applications for windows, mac os, linux, wince,
embedded linux and s60(beta). It's for c++ and java
(that's not for me) also it can make entire devices.

I think this is the way delphi need to go. You can see
the section of 'applications and devices using QT' and
the list is incredible. Simply compare to others.

In my opinion, and with the proper resources ($)
native code always will be more fast and more reliable.
Comment by Francis on November 10, 12:29

Delphi Native Code Fast or Reliable?  

QT is a good example of "looks alien or looks ugly" 
way of developing multiplatform GUIs. There are still 
too many differences in widget sets and interaction 
rules to develop a good user interface using the same 
framework on different platform. Look at Skype: it 
uses Qt on Linux, but it uses native Delphi controls 
on Windows. Which interface is better?
Delphi already attempted a Qt library (CLX used Qt, 
AFAIK), and it didn't succeeded.
Comment by Luigi D. Sandon on November 10, 14:04

Delphi Native Code Fast or Reliable?  

@Hadi: "Should we all just use ASM?"

Don't knock it.

I spent my formative years programming in ASM. When I
disassembled my first Turbo Pascal program down to
ASM, I was surprised how recognizable it still was,
without being verbose.

In the same way that Basic has morphed from line
number based, to procedural, to pseudo-object, and now
to fully object-oriented, there is no technical reason
why ASM couldn't be changed in the same way.

The first C was originally just ASM macros, and the
first C++ was just C macros.

Of course there's no market so it will never happen.
But ASM is not as scary as some people think. Try
disassembling some .NET code (Microsoft provides the
tools). You will still recognize the source and after
a bit may even try modifying the CIL P-code manually!
Comment by Ken Knopfli on November 12, 13:33

Delphi Native Code Fast or Reliable?  

Incidentally, below .NET, Java and (I think) Delphi is
machine code. .NET CIL and Java definitely don't go
through an assembler stage, and IIRC, TurboPascal was
the first compiler to forego the assembler and link
directly to machine code.
Comment by Ken Knopfli on November 12, 15:36

Delphi Native Code Fast or Reliable?  

@Knopfli: assembly is just a human readable form of 
machine code. An assembler just turns the mnemonics 
into their equivalent numeric codes, and resolve the 
addresses.
Most native compiler just outputs machine code 
directly - only a few produce an intermediate output 
that needs another compiler/assembler to produce the 
final executable.
Linking is a different task - it means combining 
object files (already in machine code...) into an 
executable and relocating addresses. Until 
TurboPascal 4.0, TP didn't link at all - it just 
produced simple .com executables, while assemblers 
may need a linker too to produce more complex 
executables.
Below .NET and Java there is a machine independent 
code (bytecode) - which needs to be interpreted or 
compiled into final machine code to be executed - 
usually by the VM.
Comment by Luigi D. Sandon on November 13, 10:55

Delphi Native Code Fast or Reliable?  

 No, Marco, you're not getting old, it's the amount of 
garbage that microsoft some times makes us eat that 
makes it so difficult to know what´s going to happen 
in five years. The real truth is: they need to change 
a lot, they need to change fast, because that makes 
the market running after their technology, that´s the 
real microsoft strategy. But with cloud competing 
becoming stronger and stronger and the open source 
community also delving into more and more end user 
programs, I don´t think microsoft's strategy is going 
too far. The good example comes from Windows 7 where 
they had to go back to supporting "old" applications 
from XP. So that´s what´s happening today: they are 
getting stuck in their own whole, isn't that sad?
Comment by Luis Carvalho on July 5, 06:33

Delphi Native Code Fast or Reliable?  

It is fast... It is faster than p-code. I think 
managed code is absolutely p-code. Non-programmers or 
poor coders are using .NET platform (same as old VB 
programmers)
Comment by Volk on July 13, 16:47

Delphi Native Code Fast or Reliable?  

Luigi,
It's more than 2 years I'm developing using Qt in 
windows and I can assure you it uses platform native 
theming engine for controls on its target platform.

Look here: http://doc.trolltech.com/qq/qq13-
styles.html
Brief:
Qt applications are given a native look and feel on 
every platform, either by emulating the native style 
or by using the system's theming engine. Since 2.0, 
Qt also lets you customize the look and feel through 
its sophisticated style API, a feature that is 
especially useful for Qt/Embedded since mobile 
devices usually require customized user interfaces. 
.
.
.
The API also proved to be powerful enough to 
accommodate two new styles: QWindowsXPStyle and 
QMacStyle. Each of these styles uses the native 
theming engine on its target platform.
Comment by Reza Jahanbakhshi on April 7, 23:16


Post Your Comment

Click here for posting your feedback to this blog.

There are currently 0 pending (unapproved) messages.