Thank you Matthew for the explanation.

If I understand correctly,

* Alex Harsanyi's start-up time is due to run-time (phase 0) initialisation 
code in the required libraries, including things like (define v 
costly-expression), which look like they could be saved as constants, but 
actually involve running the expression.

* If Alex Harsanyi's code uses dynamic-require or eval, the phase 1 
initialisation code of the required libraries is executed when eval or 
dynamic-require are first invoked.

* The size of the bytecode does matter (and switching to Chez scheme's run-time 
could hopefully improve that)

Concerning the definition of a macro:

;; a.rkt
#lang racket
(require "b.rkt")
v

;; b.rkt
#lang racket
(require "c.rkt")
(provide v)
(define v (foo))

;; c.rkt
#lang racket
(provide foo)
(require racket/function)
(define-syntax foo (curry (λ (v stx)
                            (displayln v)
                            #'1)
                          (begin (displayln "XX")
                                 (string-append "c" "c"))))

* The "cc" is printed when compiling b.rkt, but not when running a.rkt, nor 
when compiling a.rkt.

* The curry and string-append are executed when compiling c.rkt, when c.rkt is 
instantiated because it is required by b.rkt, and another fresh instantiation 
of c.rkt is done when it is transitively required by a.rkt. This can be seen by 
running raco make c.rkt; raco make b.rkt; raco make a.rkt, and observing that 
XX is printed each time.

* When executing racket a.rkt, no XX is printed unless eval is called at 
run-time at some point.

My conclusions, in terms of performance hints are that:

* It is safe to put code within the body of a transformer function (bound to a 
macro).

* Code outside of transformer functions (to define compile-time constants, or 
the curry in the example above) has a cost when compiling all files which 
transitively require that module. It also has a one-time run-time cost if/when 
eval, dynamic-require or something similar is used.

* The bytecode size has an impact too.

* It is therefore better to avoid requiring too many modules if they are not 
needed.



It would be nice to find a way to detect what code gets executed when a module 
is required, at the various meta-levels. Maybe running raco cover on an empty 
file containing only (require some-module) could help?



I'm not sure how submodules fit in this picture (the main concerns being the 
test submodule, and the doc submodule for literate programs).

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to