► |  | The Racket Reference

1 | Language Model
2 | Notation for Documentation
3 | Syntactic Forms
4 | Datatypes
5 | Structures
6 | Classes and Objects
7 | Units
8 | Contracts
9 | Pattern Matching
10 | Control Flow
11 | Concurrency and Parallelism
12 | Macros
13 | Input and Output
14 | Reflection and Security
15 | Operating System
16 | Memory Management
17 | Unsafe Operations
18 | Running Racket
| Bibliography
| Index

▼ | 18 | Running Racket

18.1 | Running Racket or GRacket
18.2 | Libraries and Collections
18.3 | Interactive Help
18.4 | Interactive Module Loading
18.5 | Debugging
18.6 | Controlling and Inspecting Compilation
18.7 | Kernel Forms and Functions

► | 18.6 | Controlling and Inspecting Compilation

18.6.1 | Compilation Modes
18.6.2 | Inspecting Compiler Passes

On this page:

18.6.1`` Compilation Modes
18.6.1.1`` BC Compilation Modes
18.6.1.2`` CS Compilation Modes
18.6.2`` Inspecting Compiler Passes

top ← prev up next →

#### 18.6`` Controlling and Inspecting Compilation

Racket programs and expressions are compiled automatically and on-the-fly. The raco make tool (see raco make: Compiling Source to Bytecode) can compile a Racket module to a compiled ".zo" file, but that kind of ahead-to-time compilation simply allows a program takes to start more quickly, and it does not affect the performance of a Racket program.

##### 18.6.1`` Compilation Modes

All Racket variants suppose a machine-independent compilation mode, which generates compiled ".zo" files that work with all Racket variants on all platforms. To select machine-independent compilation mode, set the current-compile-target-machine parameter to #f or supplying the --compile-any/-M flag on startup. See current-compile-target-machine for more information.

Other compilation modes depend on the Racket implementation (see Implementations).

##### 18.6.1.1`` BC Compilation Modes

The BC implementation of Racket supports two compilation modes: bytecode and machine-independent. The bytecode format is also machine-independent in the sense that it works the same on all operating systems for the BC implementation of Racket, but it does not work with the CS implementation of Racket.

Bytecode is further compiled to machine code at run time, unless the JIT compiler is disabled. See eval-jit-enabled.

##### 18.6.1.2`` CS Compilation Modes

The CS implementation of Racket supports several compilation modes: machine code, machine-independent, interpreted, and JIT. Machine code is the primary mode, and the machine-independent mode is the same as for BC. Interpreted mode uses an interpreter at the level of core linklet forms with no compilation. JIT mode triggers compilation of individual function forms on demand.

The default mode is a hybrid of machine-code and interpreter modes, where interpreter mode is used only for the outer contour of an especially large linklet, and machine-code mode is used for functions that are small enough within that outer contour. “Small enough” is determined by the PLT_CS_COMPILE_LIMIT environment variable, and the default value of 10000 means that most Racket modules have no interpreted component.

JIT compilation mode is used only if the PLT_CS_JIT environment variable is set on startup, otherwise pure interpreter mode is used only if PLT_CS_INTERP is set on startup, and the default hybrid machine code and interpreter mode is used if PLT_CS_MACH is set and PLT_CS_JIT is not set or if none of those environment variables is set. A module compiled in any mode can be loaded into the CS variant of Racket independent of the current compilation mode.

The PLT_CS_DEBUG environment variable, as described in Debugging, affects only compilation in machine-code mode. Generated machine code is much larger when PLT_CS_DEBUG is enabled, but performance is not otherwise affected.

##### 18.6.2`` Inspecting Compiler Passes

When the PLT_LINKLET_SHOW environment variable is set on startup, the Racket process’s standard output shows intermediate compiled forms whenever a Racket form is compiled. For all Racket variants, the output shows one or more linklets that are generated from the original Racket form.

For the CS implementation of Racket, a “schemified” version of the linklet is also shown as the translation of the linklet form to a Chez Scheme procedure form. The following environment variables imply PLT_LINKLET_SHOW and show additional intermediate compiled forms or adjust the way forms are displayed:

- PLT_LINKLET_SHOW_GENSYM — prints full generated names, instead of abbreviations that may conflate different symbols

- PLT_LINKLET_SHOW_PRE_JIT — shows a schemified forms before a transformation to JIT mode, which applies only when PLT_CS_JIT is set

- PLT_LINKLET_SHOW_LAMBDA — shows individual schemified forms that are compiled within a larger form that has an interpreted outer contour

- PLT_LINKLET_SHOW_POST_LAMBDA — shows an outer form after inner individual forms are compiled

- PLT_LINKLET_SHOW_POST_INTERP — shows an outer form after its transformation to interpretable form

- PLT_LINKLET_SHOW_JIT_DEMAND — shows JIT compilation of form that were previously prepared by compilation with PLT_CS_JIT set

- PLT_LINKLET_SHOW_PATHS — show lifted path and serialization information alongside a schemified form

- PLT_LINKLET_SHOW_KNOWN — show recorded known-binding information alongside a schemified form

- PLT_LINKLET_SHOW_CP0 — show a schemified form after transformation by Chez Scheme’s front-end optimizer

- PLT_LINKLET_SHOW_ASSEMBLY — show the compiled form of a schemified linklet in Chez Scheme’s abstraction of machine instructions

When the PLT_LINKLET_TIMES environment variable is set on startup, then Racket prints cumulative timing information about compilation and evaluation times on exit. When the PLT_EXPANDER_TIMES environment variable is set, information about macro-expansion time is printed on exit.

top ← prev up next →