[FACT] - Delphi Faster Then VB!

Article: Click Here

Extract:

Benchmarks

Delphi's superior performance over Visual Basic becomes
immediately apparent when running a few simple benchmarks.
Consider the following examples, where a database is filled with
items of text representing lastname, firstname, phone and street
information. The phone number field is filled with consecutive
integers, then the database is re-read and filled with a global
array of integers from the phone number field. Finally, the
global array is sorted to become reverse-ordered using a
comparatively slow bubble sort algorithm.

Similar code can be written in both Delphi and Visual Basic, with
the stages of the benchmarks summarized in the following code
fragments:



VB - Fill
---------
Sub btnFill_Click ()
Dim k As Integer
MaxArray = EdArraySize.Text
For k = 1 To MaxArray
Data1.Recordset.AddNew
Data1.Recordset("LastName") = "Smith " + Str(k)
Data1.Recordset("FirstName") = "Joe " + Str(k)
Data1.Recordset("Phone") = Str(k)
Data1.Recordset.Update
Next k
Data1.Recordset.MoveLast
End Sub

VB - Read
---------
Sub btnSearch_Click ()
Dim k As Integer
Dim n As Integer
Dim s As String
Data1.Recordset.MoveFirst
For k = 1 To MaxArray
s = edPhone.Text
n = Val(s)
Call AppendArray(k, n)
Data1.Recordset.MoveNext
Next k
End Sub

VB - Sort
---------
Sub btnSort_Click ()
Dim j As Integer
Dim k As Integer
Dim tmp As Integer
For j = 1 To MaxArray - 1
For k = 1 To MaxArray - j
If GlobArray(k) < GlobArray(k + 1) Then
' Swap GlobArray[k+] with GlobArray[k] ...
tmp = GlobArray(k + 1)
GlobArray(k + 1) = GlobArray(k)
GlobArray(k) = tmp
End If
Next k
Next j
End Sub


Delphi - Fill
-------------
procedure TForm1.Button4Click(Sender: TObject);
var
k,err: integer;
s: string;
begin
val(edDBsize.Text,maxArray,err);
for k:=1 to maxArray do
with Table1 do
begin
str(k,s);
Append;
FieldByName('Lastname').AsString := 'NewGuy'+s;
FieldByName('Firstname').AsString := 'Paul'+s;
FieldByName('Phone').AsString := s;
Post;
end
end;

Delphi - Read
-------------
procedure TForm1.btnSearchTestClick(Sender: TObject);
var
s: string;
n,err,k: integer;
begin
val(edDBsize.Text,MaxArray,err);
Table1.First;
for k:=1 to MaxArray do
begin
s := DBedPhone.EditText;
val(s,n,err);
AppendArray(k,n);
Table1.Next;
end;
end;

Delphi - Sort
-------------
procedure TForm1.btnSortArrayClick(Sender: TObject);
var
j,k,tmp: integer;
begin
for j:=1 to MaxArray-1 do
for k:=1 to MaxArray-j do
if GlobArray[k] < GlobArray[k+1] then
begin
{ Swap GlobArray[k+] with GlobArray[k] ... }
tmp := GlobArray[k+1];
GlobArray[k+1] := GlobArray[k];
GlobArray[k] := tmp;
end;
end;

Benchmark Results

The following table shows the results for database tables ranging
in size from 100 to 4000 records. The test stages Fill, Read and
Sort correspond the code sections described on the previous
pages.
(All benchmark times are in seconds.)

D = Delphi
FL = Fill
RD = Read
X = x Sort
ST = Sort

-----------------------------------------------------------------
# D VB D VB D X VB D X Total VB
items
FL FL RD RD ST ST Total Total
-- -- -- -- -- -- ----- -----
100 2 2 30 1 0 0 0 2 1.5 3

1000 16 70 6 23 1 22 22 23 5 115

2000 33 141 12 46 4 21 84 49 5.5 271

3000 50 227 17 69 8 23.6 189 76 6.4 485

4000 67 297 23 77 15 19.6 294 106 6.3 668
-----------------------------------------------------------------


As can be seen from the results, the resulting Delphi-generated
code outperformed the Visual Basic routines, especially in
code-bound portions such as the Sort stage, by about 20 times
faster. Delphi's database access functionality was also shown to
be about five times more efficient than that of the Visual Basic
code.

I always knew i could prove Delphi to be faster then VB, and not my words, but as the article says, far more SUPERIOR :eek:

Its also worth noting:

* Pascal is a more powerful and structured language than
Basic.

* Object Pascal is a true object-oriented programming
language, providing the benefits of inheritance,
encapsulation and polymorphism;

* Pascal is a compiled language, ensuring high-performance
executables;

* The organization of files as DCUs provides a cleaner
mechanism for creating libraries of reusable code (see
Shared Event Code);

* Object Pascal utilizes the world's fastest commercial
compiler technology;

* Object Pascal support in-line assembler code for maximum
performance;

FACT: Assembly faster than Delphi

Your point being?

Assembly is not RAD: your point being?

This is a quite narrow scale comparison. I'd like to know more about the lower level speed (math). Another thing is... this is written by the Delphi support staff, they don't tell what database they used as a backend (which makes a huge difference afaik), the article is from the year 1998 and it also includes a lot of "these are the reasons Delphi is a kickass language". I see no reason to give any value to this article.

If you want to give fact information, you either do the tests yourself or find a proper benchmark written in neutral perspective where we can be sure both codes are really doing the exact same thing.

WELL, heck then! Let's all just jump ship and switch everything over to Delphi.


I mean really, was this necessary? I'm sick and tired of these silly pissing contests. So freaking what if Delphi is faster than VB? So is C++. Big whoopty doo. The last time I looked I didn't see too many Delphi jobs available out there.

The database testing is not apples to apples comparison anyways. In VB they used the Data Control, which is not very efficient. Also they call a sub AppendArray, but don't provide details on what it does. For all we know it could be doing some highly inefficient array manipulation.

* Pascal is a more powerful and structured language than
Basic.
-- So what? Actualy, I've seen other languages that were even less structured than VB.

* Object Pascal is a true object-oriented programming
language, providing the benefits of inheritance,
encapsulation and polymorphism;
-- Until .NET came along, we've all known for sometime this was the case. Those of us that needed to do this, found a way to do it.

* Pascal is a compiled language, ensuring high-performance
executables;
-- This is one reason any comparison to VB is bull chips. It's like comparing an apple to a frozen bannana. VB is an interpreted language. And it's been that way form day one. And just because something can be truly compiled to an exe doesn't make it efficient. That is up to the developer. IT doesn't take much to cockup some code making it run inefficient. Full compiling jsut means it will be innefficient that much faster.

* The organization of files as DCUs provides a cleaner
mechanism for creating libraries of reusable code (see
Shared Event Code);
-- No idea what a DCU is, so I'll leave that alone.

* Object Pascal utilizes the world's fastest commercial
compiler technology;
-- Sooo... it compiled faster? That'll make the end users happy.

* Object Pascal support in-line assembler code for maximum
performance;
-- If you are using inline assembly, then you shouldn't be using any language and might as well go straight to assembly then. If you've gotten to this level, then it's obvious that performance is that important to you. In which case, almost any language is simply going to get in the way.

Now answer me this:
When's the last time you saw Delphi/Pascal used to create a dynamic website?
When's the last time you saw Delphi/Pascal used to create an app for a handheld device?
How often have you seen Delphi/Pascal used to automate a task using Office products?
How fast can you develop a Notepad app that allows the user to open a file, make changes and save it?

Any comparison to any language doesn't hold water for me. They all have their pros and cons. VB was never about speed, other than in the RAD department. That's what it was all about. Otherwise this would be the CPPForums. Funny thing is that even if it was, I'd bet we'd still be having this conversation.

Tg

Ok, now I know the comparison is bull.

Here's a quote from the article: "Visual Basic custom controls are referred to as VBXs, and a limited selection is supplied with Visual Basic itself."

VBXs?? That seems to indicate VB4...maybe VB5....

As Merri pointed out, the comparison is nearly 10 years old and has no bearing on today's technology.

Tg

Quote:

---

Originally Posted by yrwyddfa

FACT: Assembly faster than Delphi

Your point being?

---

My point is: who the hell cares? So what's your point?

Quote:

---

Originally Posted by techgnome

VBXs?? That seems to indicate VB4...maybe VB5....

---

Ah, forgot to mention about that. OCX was introduced in 32-bit VB4. VBX was last supported by 16-bit VB4, if I remember correctly (might not be). If they were doing the benchmark with VB4, I don't wonder at all if VB lost badly: heck, VB4 used P-code and didn't compile native applications!


My addition to this thing is that there isn't much comparison with languages: if speed comes into play, the end result is more about the programmers skill than the used language. I've already beat C code a few times with VB6 when it has come to speed comparisons. Also, it doesn't matter much when you get into the certain level of speed: what is fast is fast and you can do that with VB or any non-interpreted language if you need to.

Quote:

---

Originally Posted by Merri

Ah, forgot to mention about that. OCX was introduced in 32-bit VB4. VBX was used by 16-bit VB4, if I remember correctly (might not be).


My addition to this thing is that there isn't much comparison with languages: if speed comes into play, the end result is more about the programmers skill than the used language. I've already beat C code a few times with VB6 when it has come to speed comparisons. Also, it doesn't matter much when you get into the certain level of speed: what is fast is fast and you can do that with VB or any non-interpreted language if you need to.

---

I agree entirely. Algorithmic choice, and implementation far outweighs any perceived performance gain achieved from the compiler.

And as it hasn't been mentioned: any language is capable of compiling to fast machine code. It is a function of the compiler, not the language layout, per se.

When you deride VB (in terms of speed) you are derriding the compiler not the language.

This is, of course, self evident . . . .

Quote:

---

Originally Posted by yrwyddfa

FACT: Assembly faster than Delphi

Your point being?

---

Agreed,

if you are going to use delphi your entire life because you think other languages are too slow.. you may as well get out the soldering iron and start constructing AND gates!!

I think the sole fact of there being articles written about this proves delphi developers needing "something to prove" to keep their own self worth intact

geez ill delete the post if all you morons want to spit your dummy out over it!

Quote:

---

Originally Posted by Madboy

geez ill delete the post if all you morons want to spit your dummy out over it!

---

:lol:

I think that consensus view is that no language is faster than the others. It's simply a function of algorithms, then compiler technology: algorithms being the most significant.

An algorithm coded badly in Delphi will be vastly outperformed by a well coded one in VB and vice versa.

But at the end of the day who cares. My users don't notice a nanosecond difference in pointer indirection. Do yours?

This benchmark does not state whether VB6 was told to compile to PCode or to native binary, that makes a massive difference to the final performance. Also you never specified if VB6 was asked to optimize for speed or small exe size.

Making VB6 compile to Native with optimization for speed will be the best way to test its efficiency.

Knowing your famous vendetta against VB I imagine you set it to compile to PCode and optimize for small exe size to get the slowest results you could. :D

I agree with Phill and that welsh guy though. It really doesn't matter which is faster, they are both obsolete languages anyway.

I am not Welsh, you are not a cat, and obsolesence is a state of mind

That article is a load of rubbish.

You cannot expect anyone to take a benchmark seriously without providing every single detail about how it was conducted. And they have only posted a fraction of the code. It calls procedures which for all we know could be ridiculously inefficient.

Wossy's right. Both languages are obsolete anyway. And I agree with yrwyddfa and Merri. If it compiles properly, then it doesn't really matter what language you use, it is more to do with how well you code it.

You read the whole article, or just what i posted?

It doesn't change much anything even if he read the whole article.

I read the whole thing.... penagate still said it better than I could.

Tg

Quote:

---

Originally Posted by Madboy

You read the whole article, or just what i posted?

---

The whole article.

The full McCoy ;)

I mean lets look at the first bit of VB code:

VB Code:

Sub btnFill_Click ()
Dim k As Integer
MaxArray = EdArraySize.Text
For k = 1 To MaxArray
Data1.Recordset.AddNew
Data1.Recordset("LastName") = "Smith " + Str(k)
Data1.Recordset("FirstName") = "Joe " + Str(k)
Data1.Recordset("Phone") = Str(k)
Data1.Recordset.Update
Next k
Data1.Recordset.MoveLast
End Sub

What a pile of bovine excrement. It would be much better written like this:

VB Code:

Sub btnFill_Click ()
 
   Const SURNAME as String = "Smith "
   Const FIRSTNAME as string = "Joe "
 
   Dim k As Long
 
   MaxArray = EdArraySize.Text
 
   With Data1
 
      For k = 1 To MaxArray
         .Recordset.AddNew  
         .Recordset("LastName") = (SURNAME & CStr(k))
         .Recordset("FirstName") = (FIRSTNAME & CStr(k))
         .Recordset("Phone") = CStr(k)
         .Recordset.Update
      Next k
 
      .Recordset.MoveLast
 
   End With
 
End Sub

. . . and from just the simple changes I made would increase the performance of this code at least 10 fold.

The author of the original code is stupid and ignorant . . . and should've been culled at birth (OK only joking about the last bit - but I'm sure you get the idea)

The author of the code if he/she is not actually a lobotomy sufferer must have know VB very well. The original code makes lots of use of the variant datatype which is the slowest of them all.

The code is loaded, the article is loaded, and what the hell are we doing talking about Delphi anyway. Delphi, I'm sure you remember from your school days, was renowed for the Delphic oracle,

I suppose we're going to have cr@p performance criteria between SQL Server, and Oracle, now, are we?

May I intervene? What is Delphi? :confused: :D

Delphi is an ancient city. Ancient being the key word, here.

In simplest terms: Delphi = Visual Turbo Pascal....

Tg

Quote:

---

Originally Posted by yrwyddfa

It would be much better written like this:....

---

It would also be better to put "CStr(K)" into a variable at the start of the loop rather than calculate it 3 times, and a significant improvement could be gained by using a normal recordset as opposed to one in a Data Control.

However, as has already been stated the article is seriously out of date, and pretty much irrelevant.

Quote:

---

Originally Posted by si_the_geek

It would also be better to put "CStr(K)" into a variable at the start of the loop rather than calculate it 3 times, and a significant improvement could be gained by using a normal recordset as opposed to one in a Data Control.

However, as has already been stated the article is seriously out of date, and pretty much irrelevant.

---

Yup, that's very true. I didn't try to optimise it fully, I just wanted to show that the code was obviously cr@p

Quote:

---

Originally Posted by yrwyddfa

and from just the simple changes I made would increase the performance of this code at least 10 fold.

The author of the original code is stupid and ignorant . . . and should've been culled at birth (OK only joking about the last bit - but I'm sure you get the idea)

---

The author made it sloppy, as too the Delphi code sloppy purely for benchmarking tests. The delphi code could be optimized much greater too, but lets just forget about it.

I like Delphi simply because its VB, just slightly different syntax, better IDE and better all around. Thats my opinion, but i did use VB for 2 years before, so i should know which is best. I like the fact that in Delphi you can make a simple app and not need to bundle with it the VB runtime libraries.

So, what does this all have to do with "Code It Better"? If we're not doing things well but benchmark using a sloppy code, how can we know that the codes are sloppy equally? You can only compare two things speed if you do them the same way or make them as quick as possible. And when it comes into it, it is pretty likely they both perform well enough so it doesn't matter.

You see, this isn't anymore if Delphi is better than VB or not. You came and posted a claim with a proof which was noticed by about everyone else to be outdated, biased and badly made. Then you just go on telling how great Delphi is. Really, that isn't what interests here. It is like the Windows versus Linux wars: Windows might have its weak points, but so does Linux. Same goes for VB and Delphi. The good points are made good enough so people can use what they like to use. With the current way you're pushing Delphi here, we just get more negative image of Delphi.

I'm not telling you to use FreeBASIC only because I think it has promise to become a good basic compiler for both Windows and Linux. I can only recommend it. Find a reason to recommend Delphi. With a claim that isn't already done well enough in any VB. And then see if it matters. A personal opinion doesn't matter.