You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the compiler isn't very smart when linking an application. Ideally, only the library code that is relevant to the application should be kept in the generated application.
To achieve this, the compiler and linker can do a reachability analysis to determine which procedure definitions are "reachable" (called) from top-level expressions and also other reachable procedures.
This is rather easy to implement, but it will not give good results as-is because of how the runtime library is written. If we think of exception handling, currently the runtime system will check a run time flag to see if a REPL should be started. Given that even a tiny program might raise exceptions (for example + applied to non-numbers), the implementation of the repl (procedure ##repl) is always reachable, and consequently so is the procedure eval, the reader, the printer, the I/O subsystem, etc. Basically nothing can be eliminated because eval can access anything dynamically.
So for the most part, to achieve the goal of small applications, it is necessary to rethink the organisation of the runtime library with tree shaking in mind.
The text was updated successfully, but these errors were encountered:
Just a quick observation that the "import" statements generated by some targets should be turned into features so that they are only included if really necessary. This will help reduce load time and memory footprint.
Estimated time: 40 hours
Currently the compiler isn't very smart when linking an application. Ideally, only the library code that is relevant to the application should be kept in the generated application.
To achieve this, the compiler and linker can do a reachability analysis to determine which procedure definitions are "reachable" (called) from top-level expressions and also other reachable procedures.
This is rather easy to implement, but it will not give good results as-is because of how the runtime library is written. If we think of exception handling, currently the runtime system will check a run time flag to see if a REPL should be started. Given that even a tiny program might raise exceptions (for example
+
applied to non-numbers), the implementation of the repl (procedure##repl
) is always reachable, and consequently so is the procedureeval
, the reader, the printer, the I/O subsystem, etc. Basically nothing can be eliminated because eval can access anything dynamically.So for the most part, to achieve the goal of small applications, it is necessary to rethink the organisation of the runtime library with tree shaking in mind.
The text was updated successfully, but these errors were encountered: