I'm not so familiar with scheme, but I can perhaps give useful answer regarding how this works with SBCL (Probably the most well known common lisp implementation).
In SBCL, we would commonly say that code is "evaluated" rather than compiled or interpreted. This is because "compiler" is referring specifically to when assembly is emitted and "interpreter" is referring to when code is being used to call already compiled code. In the case of SBCL, it is doing both of these things simultaneously when it is reading a ".lisp" file. For example, if this is the contents of my .lisp file:
(defun boop () (print "hello"))
(boop) ;; prints hello
(defun scoop () (print "goodbye"))
The boop function is being evaluated (and therefore compiled), and then called on the next line. In traditional algol based languages like c and java with a separate compilation phase, it would not be possible to call boop before scoop has been turned into machine code.
So you are asking how the costs of evaluating lisp are distributed?
For one, the assembler generated whilst evaluating the .lisp file can be cached in a .fasl file so that it does not need to be evaluated again to be loaded into other projects.
Another is that macro's can be evaluated once during function definition. e.g.
(foo) ; will print "kellog" because funky was evaluated before moob was redefined.
In this case, the cost of calling moob is trivial because it only occurs once during the definition of foo. It will slow down the initial load of your program, but no subsequent calls to foo.
In SBCL, we would commonly say that code is "evaluated" rather than compiled or interpreted. This is because "compiler" is referring specifically to when assembly is emitted and "interpreter" is referring to when code is being used to call already compiled code. In the case of SBCL, it is doing both of these things simultaneously when it is reading a ".lisp" file. For example, if this is the contents of my .lisp file:
(defun boop () (print "hello"))
(boop) ;; prints hello
(defun scoop () (print "goodbye"))
The boop function is being evaluated (and therefore compiled), and then called on the next line. In traditional algol based languages like c and java with a separate compilation phase, it would not be possible to call boop before scoop has been turned into machine code.
So you are asking how the costs of evaluating lisp are distributed?
For one, the assembler generated whilst evaluating the .lisp file can be cached in a .fasl file so that it does not need to be evaluated again to be loaded into other projects.
Another is that macro's can be evaluated once during function definition. e.g.
(defmacro moob () `(print "kellog"))
(defun foo () (moob)) ; evaluates to (defun funky () (print "kellog"))
(defmacro moob () `(print "fish")) ; redefining moob
(foo) ; will print "kellog" because funky was evaluated before moob was redefined.
In this case, the cost of calling moob is trivial because it only occurs once during the definition of foo. It will slow down the initial load of your program, but no subsequent calls to foo.