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.
