[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Performance impact of top level definitions

From: Brian
Subject: Re: Performance impact of top level definitions
Date: Tue, 15 May 2018 09:55:34 -0700

Hi Mark,

Thanks for that explanation, it makes sense now to me.


On Mon, 2018-05-14 at 22:55 -0400, Mark H Weaver wrote:
> Hi Brian,
> Brian <address@hidden> writes:
> > Today I found that top level defines have a significant performance
> > impact on Guile (2.2.3). The following program takes about 108
> > seconds
> > to complete on my ThinkPad (an i5-5200U with Arch Linux):
> [...]
> > By simply wrapping that code in a lambda the program finished in
> > about
> > 47 seconds. Using lets instead of defines is equally effective.
> > 
> > I was quite surprised because I initially thought some optimization
> > would just substitute those useless nodes symbols away, but it
> > seems
> > like that's not the case...
> Right.  The problem is that toplevel variables can be mutated by
> arbitrary code from other modules, e.g. by 'module-set!', so the
> compiler cannot make any assumptions about what values those
> variables
> will contain at runtime.
> For non-toplevel variables, the situation is quite different.  In
> Scheme, non-toplevel variables can be accessed only from within their
> lexical scope, so if such a variable is not 'set!' from within its
> scope, the compiler knows that it can never be mutated.  In that
> case,
> it can assume that the variable will always contain its initial
> value,
> which enables a great many optimizations including partial
> evaluation.
>        Mark

reply via email to

[Prev in Thread] Current Thread [Next in Thread]