I liked this post(update: to be clear, the one by ELISHEVA). I think the original question is so general that there is no "one size fits all" answer. It think this has a lot to with what you are caching and why?

Some examples.
1. I have one function that always caches its results. It does a very expensive approximate pattern match on a DB and saves the result. How much memory it uses for this is documented (and directly related to DB size) and user can't turn it off. In a typical app, performance difference is like 5-10,000x between first and second call. Testing is easy as I just have to verify that consistent results are coming back and the performance difference is so huge that it is easy to see. The database is read only for each run, so this is easy to implement (no need to fiddle with "dirty pages", etc.

2. I have another function that is not strictly "caching" as it precomputes a whole bunch of things that I think that you are going to ask, before you ask them (actually makes it more efficient to answer a whole bunch of questions at the expense of a lot of horsepower at the beginning). This is an example of a "cooperative" thing. You have to tell me that this dataset is special via a "study" call. If you do that intelligently then overall performance speeds up dramatically. The normal api calls aren't changed. So testing is working with and without "studying" this dataset first.

3. There are lots of examples where caching although transparent to the user API, the user nevertheless knows that caching is going on. One example would be file I/O buffering, say to stdout. $|=1 turns this off.

4. If you are caching results for something that is dynamic (data changes during execution of your program), that is usually something more appropriate for the module to mess with, not "something between you and it".

5. Almost always it is not wise to cache something that is already being cached by the O/S. An example of this would be file I/O. I have one app with a large number of files >500 and after they've all been looked at once, they become memory resident due to O/S caching. I don't have to do anything. If I tried to cache these files, performance could go down as this could reduce amount of space that the O/S has to do this function more efficiently than I can.

6. I personally have no problem adding api calls that would tell the user some stats on how well the caching is working. These would be extra optional things. For example the Perl hash allows you to query numBuckets and Buckets used. So what? You don't have to know this to use it, but if you are curious, you can find this out.

7. I also have no problem with "private" calls that look at the "guts" and report how things are going. I don't export these methods or functions. Of course any user can call these with fully qualified name, at their own risk.

8. I would have some sort of test() method that is not exported to be used for module verification.

So, I see as separate things:
A) How to test that this module is actually working? This is for developer and build process.
B) How well is this caching gizmo working for me? This is mainly based upon: consistent results and measured performance differences.

sorry that I was so long winded....

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.