This is the mail archive of the
guile@cygnus.com
mailing list for the Guile project.
Re: Bad news from the module/environment front
- To: Jim Blandy <jimb@red-bean.com>
- Subject: Re: Bad news from the module/environment front
- From: Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE>
- Date: 01 Jul 1999 11:49:55 +0200
- Cc: guile@cygnus.com
- References: <199906282351.XAA29548@linux.zrz.TU-Berlin.DE> <m3d7ydwtyj.fsf@savonarola.red-bean.com>
Jim Blandy <jimb@red-bean.com> writes:
> especially the delayed consing for local environments.
memoization. In fact most of what is memoized now will
be unmemoized later when the evaluator detects that it has
memoized a macro expression:
0.02 44.23 0.01 1004 0.01 0.01 scm_eval_environment_memoize_cell_internal
0.00 44.31 0.00 642 0.00 0.00 eval_environment_update_memoized
> 1) Aubrey often chooses speed over maintainability, or
> 2) Aubrey is much, much more clever than I am, and thus his code is
> perfectly maintainable to him, while it sometimes stumps me for
> hours.
He has re-written his evaluator completely. The nice thing is that
his evaluator seems to be faster than guile's and appears to be much
more readable (at least to me). Most of the macros used in guile are
turned into function calls and although he still uses goto I can
understand what each code section does.
> This makes it clearer that almost all the slowdown is due to increased
> GC time. Why does the new environment system allocate more than the
> old one?
It is the evaluator's extend_env:
scm_extend_env (k, v, env)
{
SCM z;
SCM_NEWCELL (z);
SCM_SETCAR (z, SCM_CAR (env));
SCM_SETCDR (z, scm_acons (k, v, SCM_CDR (env)));
return z;
with every call to extend_env a cell is thrown away.
1.67 41.66 0.74 2279642 0.00 0.00 scm_extend_env
2279642 cells of garbage.
Jost