[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.
Cheers!
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