Archived

This topic is now archived and is closed to further replies.

Eric Grange

Delphi 6 performance

Recommended Posts

Hi, I''ve downloaded the D6 trial and made a small performance test... The Integer and FPU tests showed no improvements, but the string test showed D6 as being more than 5 (five) times slower than Delphi 5... On a new app, drop a button, a label and use the following code:
procedure TForm1.Button1Click(Sender: TObject);
var
   i : Integer;
   a, b : String;
   start, stop : Int64;
begin
   QueryPerformanceCounter(start);
   a:='''';
   b:='''';
   for i:=0 to 10000 do begin
      a:=a+''bfr'';
      b:=b+a;
      a:=Copy(b, 1, 10);
   end;
   QueryPerformanceCounter(stop);
   Label1.Caption:=IntToStr(stop-start);
end;
[/CODE]

After checking CPU-level code, it looks like string handling hasn''t changed, so if issue there is, it has to be with the memory manager which would be bad news (the ''b'' string grows a lot, while the ''a'' string is a small constantly reallocated bit).

Any confirmation/infirmartion on a non-Trial version would be welcome... Any alternate explanations?
    
--- Eric Grange http://glscene.org

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Darn, check if they changed compiler options? It might default to old behavior for compatibility.

I was really hoping to see the FPU code rewritten. The integer stuff has never been that bad. Im tired of stuffing my math routines in DLLs and compiling VC++ to get decent performance.
You know its bad when calling a DLL is faster than native code!

As for the strings, you''d be better off dealing with stuff as pchars and managing buffers anyway if you want C like speed.

Any math/asm wizes out there want to start working on math lib in ASM? BASM atleast now supports SIMD and 3dNOW I hope in Delphi 6.

Also how is it well is it coexisting with Delphi 5 or less?


D.Stastny


Share this post


Link to post
Share on other sites
Addendum: The proble is weirder than I first thought, and it is not the memory manager nor the string routines, it is the compiler, IDE or linker.

Now tested on 3 differents machines (2 NT, 1 Win98), the compiled application can have a performance ratio from 1 to 5000 (!!!) with only one change: drop or remove a useless TEdit or TMemo on the form....
A Delphi6 "fast" version is significantly faster than Delphi5 version, a Delphi6 "slow" version is significantly slower than Delphi5 version.
There is no impact in Delphi5 of having a useless TEdit or TMemo (as expected). This happens when the proggie is run from the IDE, or directly in windows with no IDE opened.

>Darn, check if they changed compiler options?

Nothing changed (only record alignment).

>I was really hoping to see the FPU code rewritten.

They don''t really need to rewrite everything, just to drop the legacy "fwait" they insert in the FPU code to get to VC++ performance level (that thing kills speculative and superscalar execution, ie. perf/2 for Pentium3, perf/3 for Athlon, only the P4 is safe, it''s FPU ain''t superscalar).

>As for the strings, you''d be better off dealing with stuff as
>pchars and managing buffers anyway if you want C like speed.

PChars are usually much slower than regular Delphi strings, at least, they were. The zero-terminated convention is actually a performance killer, especially for concatenations like in the code I posted.

>Any math/asm wizes out there want to start working on math lib
>in ASM?

Check the Geometry unit in the GLScene package (http://glscene.org), supports ASM FPU maths as well as 3DNow! enhanced vector maths. Often, just removing the "FWAIT" in the borland code is enough to speed things up.

>BASM at least now supports SIMD and 3dNOW I hope in Delphi 6.

It is advertized, didn''t tested yet, and won''t use anytime soon because it''s not in D5... In D5 you can use these instruction with Hori''s MMXasm expert (supports MMX, SSE and 3DNow!).

>Also how is it well is it coexisting with Delphi 5 or less?

So far, coexists pretty well. I''ve both D5 and D6 installed under the same user account in NT and Win98, no problem (I
deactivated the D6 JIT debugger though) unless that weird compiler issue is the result of this coexistence...



---
Eric Grange
http://glscene.org

Share this post


Link to post
Share on other sites
Hi...

I''ve just looked at the KOL/MCK thing posted at turbo - can''t try it anytime soon... but it looks wicked. Try testing this alternative approach. It promises faster and smaller files.

And they have a memory replacement unit... which might be a heaven sent in some cases.

kinda curious
Henri aka A-Lore

Share this post


Link to post
Share on other sites