Thanks to all those that braved the early morning to attend our session at Drupalcon DC.  We think it was a good warm-up for the full track of excellent performance and scaling sessions on Thursday.  See you next year!

Abstract
What do Fast Company, The Big Money, The Onion, Lifetime Television, SonyBMG, Flex.org, DressupChallenge.com, and NowPublic have in common?

The train leaves tomorrow, bright and early!  Tree House has been looking forward to this year's DrupalCon for months...we've got two sessions, a brand spankin' new tshirt design, and a super-secret conference swag that I am positive you have never seen before!

I’ll be helping my co-worker Thomas Wysocki give a presentation on practical aspects of scaling Drupal sites. The talk’s called Scaling Drupal: Not IF... HOW. We’ll be giving the first in a long line of talks on Thursday about performance.

Our approach is to show you some of the steps to diagnose performance problems, the tools to use to do so, and a brief overview on how to fix them. We're going to give you a full toolset of solutions to diagnose potential performance problems with your site, and start you down the road to fixing them. If you want to go more in depth about some of these topics, check out these sessions:

Since getting started with Drupal over two years ago, the sites I’ve built with it have naturally gotten bigger and bigger in scope. As your sites get bigger and bigger, you always look for ways to keep your site running as smoothly as possible, and this usually ends up meaning getting rid of queries wherever you can.

One feature of Views which is often used by module developers is the ability of a module to expose a set of default views. The calendar module, for example, provides a default calendar view in both its Drupal 5 and 6 versions. This is an obvious asset for developers of contributed modules: if your module interfaces with Views, it makes sense to provide a default view that users can modify.

Implementation and Potential Benefits

The hook used to do this is hook_views_default_views(). Since most modern sites are run off of a number of Views, you can also realize several benefits by building your sites with a custom module that implements hook_views_default_views():

1. It improves performance. Views implemented via hook_views_default_views() do not require a database query to instantiate. You will realize an even greater performance gain if you also use an opcode caching system such as APC or XCache.
2. Providing views in code will allow you to override the default view to make changes, and you can then choose to keep the changes in the database, update the module file to reflect the changes, or revert back to the version in your module file.
3. Because the view (and theoretically, changes to that view) are stored in files, you can put them in version control and see how the views used in your site change over time and revert to an earlier version without having to go to a database backup.