Word Count Contest

 BBS: Inland Empire Archive
Date: 01-06-56 (01:06)             Number: 712
From: BRENT ASHLEY                 Refer#: NONE
  To: HUGH MARTIN                   Recvd: NO  
Subj: Word Count Contest             Conf: (2) Quik_Bas
HM>Well done!  I didn't think of using PEEK to scan the buffer
HM>(I used INSTR instead), but it makes a difference (about
HM>50% faster).

   By far the best tool when writing it was bc's /a switch.  By
looking at the assembly listings you can see just how you're
saving bytes and time with one method over another.

HM>I've forgotten now exactly how the programs were judged.
HM>Was size most important or speed?  I opened and read the

  Speed, size, cleverness in that order.

HM>file using CALL INTERRUPT, which saves about 5000 bytes
HM>over QB's OPEN and GET.  That would have dropped your EXE
HM>size down to about 16K (same as mine).  That's pretty small

  Hadn't thought of that!  I wondered how some folk got it smaller.
Ethan had said when he called that some had got it smaller, and
one had got almost as fast, but at 80kbytes.

  When I first wrote it (no optimization) , it read my test file
(350k, I think) in 12 seconds.  With some tweaking I quickly got
it to 3.5 seconds (helped greatly by the idea of using the full
range of integer values rather than a long integer for the
counter), and then leapt into the /a listings to tweak
further, until I got it to about 1.7 seconds (mostly after it
dawned on me that whitespace could just be <= 32 rather than
checking for CR, LF, TAB, etc.)  The odd byte was saved by making
the DO loop do a post-comparison and putting the negative first on
the buffer adjustment, but that didn't really affect the speed.
The final change was a rearrangement of the logic so the most
likely events would be on the shortest logic path (e.g. I found
that there is usually much less whitespace than non-whitespace,
and that it was likely that there was more than one buffer-full,
so I performed the second comparisons on the less-likely events)
This was an interesting concept in that I wouldn't usually have
analysed the problem so deeply and it taught me a good lesson.
With those changes, I got to 1.47 seconds.  I've still yet to see
how I can get it any faster in QB.

  It certainly was fun - I hope they come out with a new challenge
soon!  I'd be interested to see your entry, too.  A 5k savings
would be useful in a couple of places I know...

  -----
  Brent
  -----

~~___
 X DeLuxe2 1.12 #10383 X

--- Maximus 2.00
 * Origin: The Programmer's Paradise (416)482-1470 (1:250/801)
Outer Court
Echo Basic Postings

Books at Amazon:

Back to BASIC: The History, Corruption, and Future of the Language

Hackers: Heroes of the Computer Revolution (including Tiny BASIC)

Go to: The Story of the Math Majors, Bridge Players, Engineers, Chess Wizards, Scientists and Iconoclasts who were the Hero Programmers of the Software Revolution

The Advent of the Algorithm: The Idea that Rules the World

Moths in the Machine: The Power and Perils of Programming

Mastering Visual Basic .NET