The performance of the Drupal 5 (and 5.1) comment block is much faster than the performance in Drupal 4.7, but it's still pretty slow, and the code to generate the comment block runs on every page view. In a stock drupal distribution, the comment block does not seem to depend on which user is (or is not) logged in, so it's ripe for caching.
If you want to change the number of comments displayed in the block, you need to override theme('comment_block') anyway, so that's a convenient place to put the caching code. It would probably be more robust to do this as a module -- you could create a hook_comment to clear the cache on comment deletion. I've actually done just that and may upload it when I get the chance. The disadvantage to a separate module is that the name of the block (for CSS styles) changes to the name of the new module.
// check cache
$cacheForSeconds = 60;
$cache = cache_get('phptemplate-comment-block');
if ($cache && $cache->created >= time()-$cacheForSeconds)
$items = array();
foreach (comment_get_recent(5) as $comment)
$items = l($comment->subject, 'node/'. $comment->nid, NULL,
NULL, 'comment-'. $comment->cid);
$block = theme('item_list', $items);
cache_set('phptemplate-comment-block', 'cache', $block);
This turns out to be a pretty nice win because l() is called on each comment link which does a drupal_lookup_path() each time. It's actually pretty easy and quite advantageous to apply this pattern to other blocks. There's a module which does something along these lines. I'm not sure how it would have a per-block knowledge of cache timeouts and flush triggers, but the main reason that I'm not using it is that the modules_load_all on the particular site I'm worried about is already taking up most of many page loads, so I'm trying my hardest to get rid of modules and code that needs to be loaded in memory.
By the way, this probably isn't a good idea if you have a module which might rewrite the comment block SQL to do access control or somesuch.