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;

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

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