Newer is not always better.
The MacForth Text Editor uses essentially the same Forth code that
Dave Sibley developed over 15 years ago. Sure, it has evolved new
features over the years, and newer Mac Toolbox calls have replaced
some obsolete ones. But it uses the same core that was
painstakingly tuned for optimal performance on old 68K machines
whose horsepower was feeble compared with current CPU's.
During a cleanup mission, I found an old Eudora trash archive that
was 157 megabytes as 3.3 million lines of plain ASCII text. With OS
X's nearly unlimited virtual memory, I wondered...
So, just as a lark, I tried to open it in the current Carbon
MacForth Editor (essentially the same version that Doug Hoffman uses
in QuickEdit.) Then I tried a few other common OS X Text Editors.
On 10.3.9 with my trusty old 450 MHz G4 with 576 Meg RAM, I got
these results:
Time to open and display file:
MacForth 10 sec
TextWrangler 33 sec
XCode: 47 sec (see note 1)
TextEdit: 63 sec (see note 1)
Tex-Edit Plus 206 sec (takes about this long to resize the window)
note 1: Both these scroll excrutiatingly slowly, and trying to jump
to the end of the file using the "end" key took longer than
I was willing to wait (I gave up after 10 minutes). The
disk thrashing was impressive, though.
Time for a failed case-insensitive search (search whole file)
(10 character garbage string):
MacForth 3 sec
TextWrangler 43 sec
XCode: 28 sec
TextEdit: 28 sec
Tex-Edit Plus 32 sec
To be sure, MacForth does not parse rtf, handle multiple fonts/styles,
or allow Unicode. But these are not needed for dealing with
source code.
But this is ANCIENT code in **FORTH** compared with the latest/greatest
products of optimizing C/C++ compilers.
Moral(s) of the story?
- a well-designed algorithm stands the test of time
- a tool designed for a single function will outperform one designed
to be more general purpose
- developing code on the newest, fastest CPU's may prevent
identification of major bottlenecks
- maybe Forth doesn't suck ;-)
|
