Object.opEquals, opCmp, toHash

Don nospam at nospam.com
Thu Feb 16 13:05:16 PST 2012


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.


More information about the Digitalmars-d mailing list