Editing Atari BASIC (section)

==Performance==
In theory, Atari BASIC should run faster than contemporary BASICs based on the MS pattern. Because the source code is fully tokenized when it is entered, the entire tokenization and parsing steps are already complete. Even complex mathematical operations are ready-to-run, with any numerical constants already converted to the internal 40-bit format, and variables values are looked up by address rather than having to be searched for.{{efn|This is the reason MS-BASICs only have two significant letters in variable names, they are stored in a list with only two bytes of ASCII for the name in order to improve searching time.}} Despite these advantages, in practice, Atari BASIC is slower than most other [[home computer]] BASICs, often by a large amount.{{sfn|Wilkinson|1985|p=139}}

On two widely used [[Benchmark (computing)|benchmarks]] of the era, ''[[Byte (magazine)|Byte]]'' magazine's [[Byte Sieve|Sieve of Eratosthenes]] and the [[Creative Computing benchmark]] test written by [[David H. Ahl]], the Atari finished near the end of the list in terms of performance, and was much slower than the contemporary [[Apple II]] and [[Commodore PET|PET]],<ref>{{cite magazine |url=https://archive.org/stream/creativecomputing-1983-11/Creative_Computing_v09_n11_1983_November#page/n271 |title=Benchmark comparison test |first=David |last=Ahl |magazine=Creative Computing |date=November 1983 |pages=259–260}}</ref> in spite of having the same CPU running at roughly twice the speed. It finished behind slower machines like the [[ZX81]] and even some programmable calculators.<ref name=ahl>{{cite magazine |magazine=Creative Computing |title=Creative Computing Benchmark |url=https://archive.org/stream/Creative_Computing_1984-01#page/n15/mode/2up |page=12 |date=January 1984 |first=David |last=Ahl}}</ref>

Most of the language's slowness stems from three problems.{{sfn|Wilkinson|1985|p=139}}

The first is that the floating-point math routines are poorly optimized. In the Ahl benchmark, a single exponent operation was responsible for much of the machine's poor showing.{{sfn|Wilkinson|1985|p=139}} The conversion between floating-point and 16-bit integers is also particularly slow. Internally, these integers are used for line numbers and array indexing, along with a few other tasks, but numbers in the tokenized program are stored in [[binary-coded decimal]] (BCD) format.{{sfn|Wilkinson|O'Brien|Laughton|1983|p=17}} Whenever one of these is encountered, such as the line number in {{code|GOTO 100}}, the BCD value is converted to an integer, which can take up to 3500&nbsp;microseconds.{{sfn|Crawford|1982|p=8.45}}

Another issue is how Atari BASIC implements branches. To perform a branch in a <code>GOTO</code> or <code>GOSUB</code>, the interpreter searches through the entire program for the matching line number.<ref name="dere10"/> In contrast, contemporary versions of MS-derived BASICs would search forward from the current line if the line number of the branch target was greater, thereby improving branch performance about two times on average.

A related and more serious problem is the implementation of <code>FOR</code>...<code>NEXT</code> loops. When a <code>FOR</code> statement is executed, Atari BASIC records its line number. Every time the <code>NEXT</code> is reached, it searches through the program for that line, despite it being in the same place as the last time.{{sfn|Wilkinson|1985|p=139}} All other BASICs instead record the memory location of the <code>FOR</code> statement and can immediately return to it without having to search.

The reason for this poor performance is best illustrated by a quote from one of its primary authors, Bill Wilkinson; in 1982 he stated:

{{blockquote|Personally, I have never been sure it is necessary for an interpreted language (e.g., BASIC) to be fast. Authors... have claimed that Atari BASIC is the slowest language ever created. My first impulse was to say, "Who cares?"<ref>{{cite magazine |first=Bill |last=Wilkinson |title=Insight: Atari |magazine=Compute! |date=September 1982 |page=116 |url=https://archive.org/details/BillWilkinsonArticles/page/n83/mode/2up |ref=none}}</ref>}}

One may contrast this philosophy with that of [[Steve Wozniak]]'s [[Integer BASIC|Apple BASIC]] for the original [[Apple I]] which was designed specifically to have the performance required to write games:

{{blockquote|After designing hardware arcade games, I knew that being able to program them in BASIC was going to change the world.<ref>{{cite magazine |title=The Apple Story / Part 1: Early History |magazine =Byte  |date=December 1984  |last1=Williams |first1=Gregg  |last2=Moore |first2=Rob  |page=A71
|url=https://archive.org/stream/byte-magazine-1984-12/1984_12_BYTE_09-13_Communications#page/n461}}</ref>}}

Several third-party BASICs emerged on the platform that addressed some or all of these issues. This included Wilkinson's own [[BASIC XL]], which reduced the time for the ''Byte'' benchmark from 194 to 58 seconds,{{sfn|Wilkinson|1985|p=139}} over three times as fast. On the Ahl benchmark, Atari BASIC required 405 seconds, while exactly the same code in Turbo-BASIC XL took 41.6 seconds, an order of magnitude improvement.<ref>{{cite web |title=Ahl's Benchmark? |url=http://atariage.com/forums/topic/116886-ahls-benchmark/ |date=28 November 2007}}</ref>