PSL compiler state information and literal parameter data can be used effectively to eliminate run-time schema and database lookups; resolve variables at compile time; and trim generated code paths at compile time. As a rule, if a value can be resolved at compile time (i.e., it is available at compile time and the logic determines that it will never change at run time), do so. Use the same technique for code paths. For example, if the method references a table that does not contain BLOBS and the table is a literal value, do not generate code to deal with BLOBS. Also, do not generate any run-time code to reference the table in the schema. Instead, do it all at compile time.
In some cases, it is possible to optimize method code after PSL has passed the entire program and all the method calls are resolved; all the subroutines are identified; and all the call paths are identified. This optimization occurs in various ways.
PSL optimizes database IO for the Db.getRecord method.
PSL also optimizes result set logic based on whether a result set is parsed into an external program. The postProc(n) array contains executable expressions that are created by the methods and usually dispatch to post-processor subroutines.
Use the methods(reference) array to determine whether a method has already been referenced within the program and whether it may be possible to re-use appended subroutines. This feature is used by Db.getRecord (which generates subroutines for each table $$vDb<nn>) to generate only one subroutine per table, regardless of the number of references to the method.