</code></pre></div> </div> </li> <li>constant variable initialization: All variables are initialised to some value, (‘0’, if you don’t specify anything else,) so sslc attempts to make use of that fact to remove the first assignment to a variable if the first assignment is a constant expression. <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>variable a; -> variable a := 4;
</code></pre></div> </div> </li> <li>constant propagation: checks for values assigned to variables which can be computed at compile time, and replaces relevant references to the symbol by the constant. The original store is not removed by this optimization. Global variables are considered for this optimization only if they are not marked import or export, and are not assigned to anywhere in the script. <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>a := 4; -> a := 4;
</code></pre></div> </div> </li> <li>dead code removal: Checks for and removes code which cannot be reached, either because it is hidden behind a return or because the argument to an if statement can be computed at compile time. <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>if (True) then begin -> display_msg("foo");
</code></pre></div> </div> </li> <li>unreferenced variable elimination: Checks for variables which are never referenced, and removes them. Also applies to global variables, as long as they are not marked for export. <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>variable i, j, k; -> variable i;
</code></pre></div> </div> </li> <li>unreferenced procedure elimination: Checks for any procedures which are never called, and removes them. <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>procedure foo begin return "foo"; end -> procedure foo begin return "foo"; end
</code></pre></div> </div> </li> <li>dead store removal: Removes variable assignments if the result of the variable is unused, and if the expression used to compute the value of the variable is provably free of side effects. (See <code class="language-plaintext highlighter-rouge">pure</code> keyword) <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>a := "moo"; -> a := "foo";
</code></pre></div> </div> </li> <li>store combination: Where there are two stores in a row to the same variable, the two expressions are combined. <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>var1 := var2; -> var1 := var2 + var3;
</code></pre></div> </div> </li> <li>variable combination: Where usage regions of variables do not overlap, combine the variables to provide additional candidates for unreferenced variable elimination. Very useful for scripts containing multiple <code class="language-plaintext highlighter-rouge">foreach</code> loops, which generate 2 or 3 hidden variables each. <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>a := "foo"; -> a := "foo";
</code></pre></div> </div> </li> <li>namelist compression: Fallout stores the names of all file scope variables and procedures in a namelist which is saved into the .int. Any of these that are unreferenced can be removed, and the names of global variables can be modified to make them shorter.</li> </ul> <h2 id="writing-your-own-code"> <a href="#writing-your-own-code" class="anchor-heading" aria-labelledby="writing-your-own-code"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Writing your own code </h2> <ul> <li> <p>Don’t have global scripts running any more often that you need them to. Not everything needs to be run every single frame.</p> </li> <li>Never concat constant strings with the <code class="language-plaintext highlighter-rouge">+</code> operator, as it forces the operation to be done at runtime. The compiler can cope with constant strings being placed next to each other without the need for a <code class="language-plaintext highlighter-rouge">+</code>, which results in far more efficient code as the combination is done at lex time. <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>#define GLOB_PREFIX "ts__" -> #define GLOB_PREFIX "ts__"
</code></pre></div> </div> </li> <li>Avoid function calls in <code class="language-plaintext highlighter-rouge">while</code> loops. Function calls are expensive in comparison to variable lookups, so it’s more efficient to move the function call out of the loop and store the result in a variable. <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>while i < len_array(array) do begin -> tmp := len_array(array);
</code></pre></div> </div> </li> <li> <p>Mark functions with <code class="language-plaintext highlighter-rouge">pure</code> or <code class="language-plaintext highlighter-rouge">inline</code> where relevant.</p> <ul> <li> <p><code class="language-plaintext highlighter-rouge">pure</code> is a hint to the optimizer that a procedure has no side effects. (i.e. there’s no way to tell that it’s been called aside from its return value.) Pure procedures cannot modify global variables, or call any other procedure that isn’t itself pure. Functions marked with pure can only be used in expressions (i.e. you cannot use the <code class="language-plaintext highlighter-rouge">call <procedure></code> syntax to call them.) If there are non-pure terms in an expression, it prevents that expression being considered for dead store removal. Where no such optimizations can be performed, or if optimization is disabled, marking a procedure with pure will have no effect on the compiled code.</p> </li> <li> <p><code class="language-plaintext highlighter-rouge">inline</code> is an instruction to the compiler to replace calls to the marked procedure with a copy of the procedures code instead of having a separate call. Inlined procedures cannot use the <code class="language-plaintext highlighter-rouge">return</code> command, cannot be predefined, and cannot be used as part of an expression. Inlining if a procedure is only going to be called once is always a win, but if there are multiple calls to a procedure you will end up bloating the size of the generated code.</p> </li> </ul> </li> </ul> </main> </div> </div> <div class="search-overlay"></div> </div> </body> </html>
