[Coco] a couple of programming questions

[Wayne Campbell]

Robert

I did the work, and I got results. The displays are noticeably faster. The initialization of the strings that contain the display strings and format strings takes less than a second (done at startup, before anything is displayed). The numbers. Well, I still haven't tallied the final count, but I've added over 150 string variables to contain the string parts, including the ones that contain the parts merged together to form longer strings. The average size of the instructions that previously contained the literals is cut by over 50% per instruction.

Size? The program is ~3K larger, and the data size is ~2K larger. Interestingly, the program is not slower. It is only marginally faster in execution of the overall code, however. With createmsg (I mistakenly typed 20 minute decode, when it was 2:10) the decode (over 2 runs) was 2:09 and 2:10, so maybe a few tenths of a second faster, maybe?

RConfig, the 16K procedure, went from 43 minutes to 44 minutes. I think I have an idea what caused that. I have the strings DIMed between variables that the program uses alot. I need to reposition the strings so they are at the bottom, so they will be placed at the end of data memory. This may speed up the execution time some.

I found that the code was definitely less lengthy in the print statements. For example, this:

PRINT USING "s5,i5>,x11,s6,i5>,s6,i5>,s6,i5>,s6,i5>","(80) ",b80,"|(85) ",s85," (F2) ",sf2,"|(F6) ",ff6," (89) ",f89

became this:


PRINT USING fmt20,cB80,b80,cS85,s85,cSF2,sf2,cFF6,ff6,cF89,f89

Much smaller. I believe that Basic09 accesses string variables faster than it builds a string from a literal, but I have no data to verify that.

I chose not to do the same optimization with numeric literals for one primary reason. There is no significant gain. There are no savings on anything that has a size of <4 bytes. A null string, for example, results in 2 bytes of I-Code, 90 FF. A byte literal also results in 2 bytes of code, 8D <byteVal>. A integer, and a hex integer, both result in 3 bytes of code, 8E (integer) or 91 (hex) <intVal>. Since all variables use 3 bytes of code, <token> <pointerInt>, you add a byte for each null string or byte literal. There is no difference with integer and hex.

Real values use 6 bytes, 8F <5-byteRealVal>, and are therefore good candidates for optimization, especially if they are recurring. But even one occurance would be better optimized, since the variable reference is half the number of bytes of code.

Any string 1 character or larger is a good candidate for optimization. Take " ". This one character is more used in most programs than any other character as a single-character literal. If you DIM a 1-character string, and assign it the value " ", then use it in every place where you used " ", you have added 1 byte to the data storage requirement, and 1 additional reference.

Let's say you have " " 50 times in your code. That's 50x3=150 bytes of code (50 x 9020FF). Dim the string. The assignment adds one reference, so you now have 153 bytes of code, instead of 150, and your data size is 1 byte larger. Why spend the space? Because RunB is going to retrieve that space character from the data memory and display it faster that it will calculate the value of the " " literal, especially if it has to recalculate it 50 times.

In my tests, I broke every string down to its parts and then isolated each different part. There were many like-occurrences, like "Variable" and "Variables", and repeat occurrences, like "Display". Once I had broken everything down, I found that I had many strings that could be put together to form the longer strings. I went the distance and optimized it as much as I could. Was it worth the time it took? Yes. Besides the fact that I see the displays happening more quickly, I also now see better what could be done less intensively, and without detriment to the overall execution speed.

Wayne



________________________________
From: Robert Gault <robert.gault at worldnet.att.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Fri, November 20, 2009 4:54:09 AM
Subject: Re: [Coco] a couple of programming questions

Wayne Campbell wrote:

> I'm going to test a version of decode with all of the changes/additions to see what it does. I'll report back with some results in the next day or 2.
> 
> Wayne

Now you're cooking! Running this test is the only way to tell which version would be optimal or if any differences are even detectable.

In general, a one time use of just about anything in a large program probably won't require optimization. Code that is often used or is an obvious bottleneck is where optimization give good results.

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco