If your site is left for a while, say throughout the night, and you find that hitting it for the first time in the morning (i.e. a cold start, an initial run) takes longer to load than after clearing your caches, then it's fair to assume that it's not merely a problem of caches expiring and refilling.
In Drupal 7, there's no forward-looking native method for managing hierarchical data. We do have the Book module, but it's old and hard-codes things that can be done in a more general way. For example, it's using its own database table instead of using the Field API.
We can do a better job of creating book sections and subsections, say, with some contributed modules and a little bit of recursion.
Versionable content in Drupal has always suffered from inefficient storage. Each new revision of a content item (historically a "node", but now anything that's fieldable, an "entity") is stored in its entirety in the database. For sites with lot of content, and continuous updates (new revisions) of that content, the database size can grow extremely large over time. This becomes a serious problem for maintenance and disk usage.
The Schema module, which I am now maintaining, lets you compare your actual database tables against the schema that your database is supposed to match. It's a useful tool that tells you when you've got extra tables (say from a previous version of Drupal), missing tables (that were mistakenly or maliciously dropped) or mismatched tables, ones whose implementations do not match their definitions.
I've recently added a feature which provides these lists through Drush for use on the command line or in scripts.
