TO DO
We should extend the benchmarking module to allow
timethis(main, { MEMOIZED => [ suba, subb ] })
What would this do? It would time
main
three times, once withsuba
andsubb
unmemoized, twice with them memoized.Why would you want to do this? By the third set of runs, the memo tables would be fully populated, so all calls by
main
tosuba
andsubb
would return immediately. You would be able to see how much ofmain
's running time was due to time spent computing insuba
andsubb
. If that was just a little time, you would know that optimizing or improvingsuba
andsubb
would not have a large effect on the performance ofmain
. But if there was a big difference, you would know thatsuba
orsubb
was a good candidate for optimization if you needed to makemain
go faster.Done.
Perhaps
memoize
should return a reference to the original function as well as one to the memoized version? But the programmer could always construct such a reference themselves, so perhaps it's not necessary. We save such a reference anyway, so a new package method could return it on demand even if it wasn't provided bymemoize
. We could even bless the new function reference so that it could have accessor methods for getting to the original function, the options, the memo table, etc.Naah.
The TODISK feature is not ready yet. It will have to be rather complicated, providing options for which disk method to use (GDBM? DB_File? Flat file? Storable? User-supplied?) and which stringizing method to use (FreezeThaw? Marshal? User-supplied?)
Done!
Maybe an option for automatic expiration of cache values? (`After one day,' `After five uses,' etc.)
Put in a better example than
fibo
. Show an example of a nonrecursive function that simply takes a long time to run.getpwuid
for example? But this exposes the bug that you can't saymemoize('getpwuid')
, so perhaps it's not a very good example.Well, I did add the ColorToRGB example, but it's still not so good. These examples need a lot of work.
factorial
might be a better example thanfibo
.Add more regression tests for normalizers.
Maybe resolve normalizer function to code-ref at memoize time instead of at function call time for efficiency? I think there was some reason not to do this, but I can't remember what it was.
Add more array value tests to the test suite.
Does it need more now?
Fix that `Subroutine u redefined ... line 484' message.
Fixed, I think.
Get rid of any remaining *{$ref}{CODE} or similar magic hashes.
There should be an option to dump out the memoized values or to otherwise traverse them.
What for?
Maybe the tied hash interface taskes care of this anyway?
Include an example that caches DNS lookups.
Make tie for Storable (Memoize::Storable)
A prototype of Memoize::Storable is finished. Test it and add to the test suite.
Done.
Make tie for DBI (Memoize::DBI)
I think there's a bug. See `###BUG'.
Storable probably can't be done, because it doesn't allow updating. Maybe a different interface that supports readonly caches fronted by a writable in-memory cache? A generic tied hash maybe?
FETCH { if (it's in the memory hash) { return it } elsif (it's in the readonly disk hash) { return it } else { not-there } } STORE { put it into the in-memory hash }
Maybe `save' and `restore' methods?
It isn't working right because the destructor doesn't get called at the right time.
This is fixed. `use strict vars' would have caught it immediately. Duh.
Don't forget about generic interface to Storable-like packages
Maybe add in TODISK after all, with TODISK => 'filename' equivalent to
SCALAR_CACHE => [TIE, Memoize::SDBM_File, $filename, O_RDWR|O_CREAT, 0666], LIST_CACHE => MERGE
Maybe the default for LIST_CACHE should be MERGE anyway.
There was probably some other stuff that I forgot.