From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-11-16 13:07:24
On Sat, Nov 16, 2002 at 01:32:51AM +0100, BlackJack/Civitas wrote:
> The last sentence is the reason why I still would use cbm_load/save()
> even if there's C file I/O. A cardrigde with a fastloader speeds
> loading/saving up very well.
Seeing how people argue about this, I came to the conclusion that the old
90:10 rule is still true: 90% of all programs do not have any problems with
CPU or memory limits, the other 10% do. However, 90% of all programmers
believe that especially their programs belong to the latter group.
So let me take the chance to explain why people often try to optimize in the
wrong places:-)
Let's do a few calculations. Assume, we have a *really* fast fastloader that
gives us a raw transfer speed of 5KB/sec (with most fastloaders for the C64
you will get half of that). Let's also assume that we want to transfer 256
bytes (which is not much), and that there is no postprocessing, no KERNAL
overhead and so on. Our wrapper code is rather large and adds an overhead of
2ms to fread or whatever function we're using (around 600 instructions for a
1MHz 6502, so lets call it BFW for "big fat wrapper").
Transfer of 256 bytes needs 50ms
BFW code needs 2ms
As you can easily see, even in this example, the overhead of our wrapper is
just 4%! Now think about the following: We have made our example in favour of
the fastloader. For one, with most fastloaders you get half of the transfer
rate. Second, a wrapper with 600 instructions would be about 1.2K in size
(assuming no loops), half of that is still a lot but more realistic. This
brings the overhead down to about 1%. If we are going to transfer more data
than just 256 bytes, the overhead becomes even less. And we have not even
talked about the fact, that the speed of the fastloader is the *transfer*
speed. The floppy has to position the head over the track, and wait until the
sector is under the head - things that need a real lot more additional time.
Add to that the time to lookup the directory entry when opening the file, plus
the time needed to postprocess the data, plus the overhead in the KERNAL, plus
...
I think that we can state that for most applications, the overhead is a few
tenths of a percent, fastloader or not. Is it really worth to sacrifice
portability for a speed gain of a few tenth of a percent?
BTW: Just a few hours after my longish post yesterday, I ran over an article
on Slashdot named "The Peon's Guide To Secure System Development". It has some
nice comments on portable programs and the "need for speed". See
http://m.bacarella.com/papers/secsoft/html/
if you're interested.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2002-11-16 13:07:45 CET