Static stack effects

The first step when optimizing Factor code is to ensure that it is compiled with the Optimizing compiler. A word will be optimized if and only if it has a static stack effect. To check this,

[ my-word ] infer.

You can define unit tests which assert this is true,

\ my-word must-infer

High-level optimizer

To see how the high level optimizer treats a word, you can use the following tool:

USE: compiler.tree.debugger
\ foo optimized.

You will be able to see if generic dispatch has been eliminated, and if generic airthmetic has been converted to machine arithmetic, and which words have been inlined.

You can also pass a quotation to optimized.:

[ 100 [ ] times ] optimized.

The high level compiler can be given hints and inline declarations which affects the output of the above.

Low-level optimizer

To see how the low level optimizer treats a word,

USE: compiler.cfg.debugger
\ foo test-mr mr.

Disassembly

To see the final code generated for a word, use the disassemble word.

Disassembling words is accomplished using libudis86 on x86, and gdb on PowerPC.

Note that udis needs to be compiled with the --enable-shared option:

• udis Installation

Additional advice

• Take a look at the code in the extra/benchmarks/ directory. These programs are extremely optimized, but also written in a high-level style.
• Avoid using dynamic variables in tight loops; use locals or the stack instead.
• Immutable locals and stack shuffling are equivalent semantically, and compile to the same code; pick whichever one makes for clearer code.
• Mutable locals, on the other hand, incur a performance penalty because a heap-allocated container is made to hold the mutable value.
• Don't use low-level words like fixnum+, and so on. Given the right set of inlining declarations and hints, the compiler can eliminate generic arithmetic, and the result will be safer and more readable than if you attempt these transformations by hand.
• On the other hand, unsafe sequence operations are useful sometimes when accessing sequence elements in tight loops; however, try to express your code using map, reduce, or something like that instead, since they already use unsafe operations under the hood.