On Thursday, 16 February 2012 at 21:05:19 UTC, Don wrote:
On 16.02.2012 20:10, H. S. Teoh wrote:
On Thu, Feb 16, 2012 at 01:53:46PM -0500, Jonathan M Davis
wrote:
On Thursday, February 16, 2012 09:38:54 H. S. Teoh wrote:
This is a non-problem once the compiler implements
memoization as an
optimisation. Which it can't until we go ahead with this
change.
This is the direction that we *should* be going anyway, so
why not
do it now rather than later?
I would point out that there are no plans to implement any
kind of
memoization in the language or compiler. Also, while it can
help
performance, it can also _harm_ performance. So having it
controlled
by the compiler is not necessarily a great idea anyway. It's
really
the sort of thing that should involve profiling on the part
of the
programmer.
[...]
Then I agree with bearophile that we should have @memoize (or
its
negation), so that the programmer can indicate to the compiler
that the
function should be memoized (or not).
Unfortunately, that's too simple. Although the compiler can
memoize a few simple cases, it can't do it efficiently in
general.
Sometimes it makes sense to store the memoized result in the
object, sometimes separately. Sometimes only certain cases
should be memoized --
the question of whether to memoize or not may depend on the
value of the object (you only want to memoize the complicated
cases).
It's too hard for the poor compiler.
I'll add to Don's comment a question: Compile-time memoization
means the decision is static. Shouldn't the decision tough be
made instead at run-time to account for the run-time
characteristics of the process? E.g. memoize the frequent case.
This sounds to me more in the realm of a JVM optimization rather
than a compiler one.
