I was wondering how much space some of the caching I use in BottomFeeder uses. Now, I could have copied my feed data over to my dev directory, started Bf up in the dev system, and taken a look. However, that wouldn't have given me an accurate picture of cache usage in the real system - the usage of caching happens as a side effect of real usage. What to do? Well, this is Smalltalk, not some godforsaken curly brace language - so I went right to the application. It turns out that you can pop up inspectors in Bf if you know how. So up came the inspector, and I opened the workspace pane. This is one of the truly cool things about Smalltalk - the system is truly putty in your hands. Since the whole system is there (I don't strip out the compiler; it would not be possible to do the kind of runtime updates Bf does if I did), I wrote up a quick script:

| all feeds |
all := OrderedCollection new: 1000.
feeds := RSS.RSSFeedManager default getAllMyFeeds.
feeds do: [:each | all addAll: each items].
all collect: [:each | each cachedHTML].

I inspected the results of that, and got a collection of all the cached HTML the application is hauling around. I had 8206 instances of them, and the aggregate total of characters was 300k - i.e., not worth worrying about. The nifty thing is, I was able to get a real runtime result, not an assumed result based on semi-real usage in test.

This isn't the limit of what you can do, either. Awhile back, I introduced a bug in the dev stream that resulted in the item cache sizes being set to absurdly small sizes for most feeds. That would have been painful to fix manually, so did this

RSS.RSSFeedManager getAllMyFeeds do: [:each | each feedLevelCache: 120]

Which reset all my feeds to a more reasonable level. Do I expect average Bf users to do this sort of thing? Heck no. On the other hand, it's certainly handy for me as a developer - I can get real world usage answers from the system instead of test answers that may not match up. Try that in .NET or Java :)