Re: Delphi 2005 executes slower?

On 2005-05-28, Paul Dunn <paul.dunn4@xxxxxxxxxxxx> wrote:

> 1. Programs with intense CPU usage slowed down significantly - up to 50%
> slower in some cases (though the worst were using hand coded ASM blocks - I
> assume that Delphi 2005 would be using more processor specific stuff in
> these cases). My main test for this was sound output. In one application, I
> used MMX to move memory to the sound buffer, and that one suffered a lot
> when moved to 2005. The other application used CopyMemory() which was
> significantly faster, but failed to execute on a 486.

Sounds like extra runtime handlers (for possible use of some new D2005
features), or some seriously slowed down one, or both.

> 3. Delphi 2005 alters the behaviour of my applications when recompiled. No
> asm blocks, just plain delphi-pascal. Unfortunately there's upwards of 700
> operations where the behaviour could have been changed, and I really didn't
> feel like tracking it down.

If it your library usage is basic, or if it is a numeric engine, and you
have non-complicated unit tests, you could try to give it a spin with FPC,
maybe you're lucky and its errors/warnings/hints set you on the right track
easily. It is not guaranteed, but worth a shot.

> switching back to Delphi 5. That one gives the best performance of all the
> delphi versions that I've tried (D3 - D6, D2k5) and the best reliablity.
> I've decided that Borland have lost the plot entirely, and won't be trying
> any new versions.

I've two other remarks for the thread:
- I use D6E, however with now a quite complete set of patches installed,
and those mattered a lot compared to the original D6. Afaik D2005-trial
versions are still patchless. IOW, patchlevel might level, specially
since it is 1.0 of a Delphi generation.
- I expected some major performance improvements from INLINE;, based on FPC
experiences with the similar options. In some cases I could get
applications to improve with 30-50% with a few well placed inlines in a
rate determining routine. And Delphi (still) has the better optimizer, so
it should benefit even more if the optimizer works over the final inlined
code. Anybody with experience on this? (my case was a set of (non-oop)
custom iterator routines, it optimised away the abstraction layer)
.

Relevant Pages

  • Re: About speed
    ... about 10,000,000 hands per second and when you dont use inlining the ... In delphi it is evaluating 11,500,000 hands ... - irrelevant of whether or not you used the 'inline' directive. ... SevenCardEvaluateInlinedLabel 18,343,400 hands per second ...
    (borland.public.delphi.non-technical)
  • Re: Investigating MMX instructions in Delphi.
    ... and lets you write inline MMX assembler. ... Delphi if you start doing heavy assembler optimisation is the lack of good ...
    (comp.lang.pascal.delphi.misc)
  • Re: Investigating MMX instructions in Delphi.
    ... >this last one) natively in inline asembler. ... But for older assembler, this ... I thought that Delphi aligned procedures / functions on 16 byte ... >sometimes even higher) by using properly aligned instructions, ...
    (comp.lang.pascal.delphi.misc)
  • Re: D2005 - A Hated Product!
    ... it should mark TheSameN as having not side effects (that Delphi does not) - ... after a) and b) optimizer can ) substitute/inline ... BTW, it is not my mad dream, - those compilation technics are known since 1960s and well described ... Andrew Rybenkov. ...
    (borland.public.delphi.non-technical)
  • Re: Compiler optimisation
    ... I'll admit that the optimizer in the Delphi compiler is not ... > necessary support for new language constructs), since Delphi 2. ... I didn't check Andrews statement (few posts ...
    (borland.public.delphi.non-technical)