On 29/09/11 8:01 PM, Steven Schveighoffer wrote:
Again, I ask, what is a real-world example of something that needs lazy
caching (or where lazy caching significantly helps performance) for
comparison. You have already stated that you appreciate it's not const,
so you must have *something* that needs it.
1. A renderer lazily caching world transform matrices.
2. Collision detection queries often cache recent intermediate results
due to spacial coherency between queries.
3. A simple asset loader may lazily load assets on demand (rather than
having to eagerly load things up front).
4. String hashes are cached all over the place for fast resource look ups.
I'm honestly quite amazed that I have to justify my belief that caching
is useful, and commonly used. Caches are everywhere: your CPU has
multiple levels of caches, you hard disk has caches, your browser
caches, domain lookups are cached; and they're all lazy, too. Lazy
caching is a cornerstone of optimisation.
So far, I don't think it's a very common requirement. It certainly
doesn't seem like it's so important that the entire body of D code in
existence should have to deal with mutable opEquals. The fact that it's
mutable now is really a legacy D1 issue.
Inline assembler isn't a common requirement either, but that's no
argument to ignore it.
I suppose something like __restrict isn't very important to you either.
It's certainly used a lot less than lazy caching. However, it's worth
pointing out that __restrict was introduced into compilers through
popular demand by people that needed it. These things are real and
should not be ignored.
