Hey all,
        I ran a few more test using my Fibonacci algorithm.  I got a lot
of feedback from the GCC, MSVC++, and Delphi camps.  Here are now
the fastest speeds I could attain with each tool (still using
a 486DX2/66 with no cache and 16 megs of RAM):

Delphi 2.0 on Win95 --                                  90 seconds
MSVC++ on Win95 (someone sent me an optimized EXE) --   115 seconds
GCC 2.7.0 on Linux --                                   115 seconds

Now, because the C++ compilers improved so much (MSVC++ went from 192s
to 115s, and GCC went from 129s to 115s), I am sure there are more
optimizations out there that I just didn't mess with.  On the MSVC++
I just got an "optimized for speed" EXE from a gentleman, and on the GCC,
the best time I got was with the -O2 -fomit-frame-pointer -m486
optimization flags.  The stack frame pointers really matter, because
as I mentioned in a follow-up post, turning the "Stack frames" option
on in Delphi 2.0 added some time on my 486DX4/75 ( I didn't retime
it on my 486/66.)

Interesting notes:  
- One fellow posted that on his P90, he attained times of 38 seconds for
Delphi 2.0 and 37 seconds for MSVC++ (same algorithm as my original poor one).
- One man ran the algorithm on a SuperSparc20 using a commercial C++
compiler called Centerline in 95 seconds.  He could not find any
optimization options.  Using GCC with the -O2 option he attained
a time of 90 seconds (and I am sure -fomit-frame-pointer might do
even more.)  Nice job, GCC!
- Many people wrote me and posted with better algorithms that still made
good use of recursion.  Goes to show compiler optimization and hardware
speed can generally only provide a fraction of the speed increases a
clever algorithm can (most times I got back from these new algorithms
were sub-5-seconds for items as outrageous as fib(10000)).
- It was pointed out to me by a fellow in the C++ newsgroup that
my test was "useless and over-simplified" because it utilized
differing operating systems and tools.  Maybe, but that was sort of the
point.
- THANKS TO EVERYONE WHO SENT ME E-MAIL AND ACTUALLY MADE THIS
SOMEWHAT SILLY THREAD WORTHWHILE!

I would have to say that I am beginning to agree with many of the posts
I have seen that state that speed and raw power are not as important anymore
as ease of use and quick development cycles.  In this one inane example,
all tools fared relatively similarly.  But I can absolutely state
that Delphi is easier to develop such code in, and this was not even a
Windows application.  If I had needed to utilize Windows controls,
Delphi's environment would have increased my speed over the other tools
by at least a factor of 2.

Thanks for reading!

Joe Kaufman

That was me. The only optimization feature I changed was from stdcall
to fastcall. If that explains the jump in speed on my P90, then that's
it.

Incidentally, I tried writing a simple application to fill a TList
with some objects, and did the same thing with CObArray in Visual C++.
I found Delphi ran 7 times SLOWER than Visual C++. When I switched
from TList to an ordinary array, I got equivalent speed figures again.

Pete

Pete
---
My opinions are my own, not necessarily those of my employer.

On Mon, 29 Apr 1996 07:13:28 GMT, Peter.Good...@reo.mts.dec.com (Pete

Fill a TList how? In Delphi 1or Delphi 2? Depending on what you are
trying to do, there may be a simple way to improve the performance of
a TList.

When using Delphi 1, you might find it faster to use my THugeList
replacement for TList. Not only does it hold any number of items (no
64K limit), but it is faster for many purposes. You can find it at the
web site listed below, on the freeware page.
--
Ray Lischner                              li...@tempest-sw.com
Tempest Software, Corvallis, Oregon, USA  http://www.tempest-sw.com

        For speed, he should also set the CAPACITY up front, so that reallocation every
8 items does not slow it down..... (or is it 16?)

_
******************************************************************
NOTE: This software is currently in early alpha. If you notice any
problems, or RFC non-compliance, please report it to p...@pobox.com
-Please do not report duplicates, as this is usually a manual resend
-Still working on the references problem......It WILL get fixed
+------------------------------------------------------------+
|Chad Z. Hower  -  phoe...@pobox.com                         |
|Phoenix Business Enterprises - p...@pobox.com - www.pbe.com  |
|Physically in Church Hill, TN - Logically Not Sure          |
+------------------------------------------------------------+

**Special Compile: 3.000A (Alpha)

This is with Delphi 2.0. I filled a TList with a simple class TThing
with just a string in it. Running it took about 7 times longer than
Visual C++ CObArray. When I set TList.Capacity to 10000, then it ran
at the same speed as Visual C++.

Seems like MS CObArray is better implemented than Delphi TList.

Pete
---
My opinions are my own, not necessarily those of my employer.

On Fri, 03 May 1996 10:57:52 GMT, Peter.Good...@reo.mts.dec.com (Pete

It depends on how you define "better". Better at filling a list of
10000 items, one item at a time? Apparently so. I don't know how
CObjArray is implemented, but my guess is that it consumes more memory
for small lists. If your need is for many small lists, then TList
might be "better".

To use TList optimally, preset the Capacity to the expected list size.
This is very important for very large lists, because TList grows by 16
item increments. This means lots of copying if the list is ultimately
to be 10000 items.

Now whether TList is adequately documented, so one knows when set the
Capacity, that's a different question...
--
Ray Lischner                              li...@tempest-sw.com
Tempest Software, Corvallis, Oregon, USA  http://www.tempest-sw.com