# Documentation Version for Comments and Changes

Changes will `eventually` be merged into the offical documentation.

Leave any commnents here...

...

... back to index page OE documentation

```for i = 0 to 199 do
poke(screen_memory+i*320, 0)
end for
```

becomes:

```x = screen_memory
for i = 0 to 199 do
poke(x, 0)
x = x + 320
end for
```

### Saving Results in Variables

• It's faster to save the result of a calculation in a variable, than it is to recalculate it later. Even something as simple as a subscript operation, or adding 1 to a variable is worth saving.
• When you have a sequence with multiple levels of subscripting, it is faster to change code like:
```for i = 1 to 1000 do
y[a][i] = y[a][i]+1
end for
```

to:

```ya = y[a]
for i = 1 to 1000 do
ya[i] = ya[i] + 1
end for
y[a] = ya
```

So you are doing two subscript operations per iteration of the loop, rather than four. The operations, ya = y[a] and y[a] = ya are very cheap. They just copy a pointer. They don't copy a whole sequence.

• There is a slight cost when you create a new sequence using {a,b,c}. If possible, move this operation out of a critical loop by storing it in a variable before the loop, and referencing the variable inside the loop.

### In-lining of Routine Calls

If you have a routine that is rather small, the interpreter and translator will in-line it for you. Your code will remain as readable as before.

### Operations on Sequences

Euphoria lets you operate on a large sequence of data using a single statement. This saves you from writing a loop where you process one element at-a-time. e.g.

```x = {1,3,5,7,9}
y = {2,4,6,8,10}
z = x + y
```

versus:

```z = repeat(0, 5)  -- if necessary
for i = 1 to 5 do
z[i] = x[i] + y[i]
end for
```

In most interpreted languages, it is much faster to process a whole sequence (array) in one statement, than it is to perform scalar operations in a loop. This is because the interpreter has a large amount of overhead for each statement it executes.

Euphoria is different. Euphoria is very lean, with little interpretive overhead, so operations on sequences don't always win.