Michael G Schwern wrote: > On Mon, Dec 09, 2002 at 08:36:20PM -0000, Smylers wrote: > > > That way a function could decide to cache some return values but not > > all of them. > > The example above is a classic example of premature optimization. > There's nothing which ways the cache would be counter-productive for > simple calculations since the caching logic is nearly as simple.
OK. There was something on MJD's QOTW recently where using the current Perl 5 Memoize module slowed code down -- that gave me the impression that caching had the potential. > However, if you *really* want to do partial caching and given that > this is an edge case, ... It wasn't supposed to be claiming to be a serious function where caching would be useful! > I'd say to just do it as two functions Yeah, I thought of that (thanks for bothering to write it out) then I thought of having the caching be per-C<return> and couldn't work out whether it'd be generally useful or not, which is why I asked here, for an increased sample size. And that increased sample size indicates "not", so I'll forget about it. > rather than making the caching semantics more involved. (As hard as this may seem to believe, the idea actually sprang from wanting to make caching _less_ involved. I think my brain was going along the lines of "I've just writing this expensive calculation to compute a value, let's save it somewhere before returning it" so wanting to deal with the caching at _that_ point; I hadn't thought about caching when writing the C<sub> line some time previously and it seemed inconvenient to have to go back there now that I was considering it. Or something.) Smylers
