This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Bad news from the module/environment front


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]