The KRANK feature optimizes the startup time of an application. Krank allows you, without changing the source code, to construct an application that doesn't need to run any initialization code when it starts.
The KRANK feature works by collecting data from an instrumented version of the application, and using this data to compile a version that incorporates information about the application's initial object state.
- The ?krank request parameter causes the compiler to link against an instrumented version of the LFC, and to compile the application with the krank compiler option.
- The krank compiler option attaches a 'name' property to every function, so that functions can be serialized.
- The instrumented LFC is also compiled with the krank compiler option, and includes serialization code.
- The instrumented application is served to the browser, and runs until the canvas initializes.
- The server listens to this port.
- The krank compiler on the server:
- Parses the original object file, to collect function definitions. It builds a table of functions, indexed by instrumented id.
- Writes a copy of the original object file in which all ActionScript blocks (except the preloader) have been replaced by a new block.
- The new block contains functions that are referenced int he serilized object hierarchy.
- It also contains bytecodes that recreate the object hierarchy that, in the original application, were created by initialization functions.
- listens on the krank port, and serializes the movie and object serialization documents to disk
- responds to periodic requests from the front end to display the status of the krank operation
- jython->Java adaptor for the reserialization code
- Adaptor to attach the serialized movie clips to the new object file
- functions to collect function definitions from a swf file
- parsing and writing swf files
- obj2as.py ("object to ActionScript")
- sermc.rnc, serobj.rnc
- RELAX NG Compact schema for the serialized XML movieclip and object hierarchies
obj2as.py is convoluted because it uses SAX instead of DOM. (The initial DOM implementation ran out of memory too quickly.) We wrote this before pulldom existed; it would be a better way to do this, and would allow the removal of the internal stack.
The swf is parsed several times. An object representation would be more efficient.