I came across a couple of interesting articles today:

Why Drupal is so slow
Why Drupal is so slow (part 2)

I found them while googling various Drupal API functions. It's somewhat ironic that I read these searching for docs on Drupal's API because just prior to searching, I was thinking to myself, Drupal has an API? Hmm, well I guess with all those module and theme developers, they need to have some standard method for extending the core. I wonder how much this costs in terms of a performance hit?

In my short experience with Drupal, it's not slow but it isn't fast either. The server that I'm using to run Drupal is actually fast by today's standards with plenty of memory to boot. Yet, page loads are just not what I'd call zippy. I admit the sluggishness may be attributable to many factors, e.g. too much content, a heavy theme, a buggy module, etc. Believe it or not, it is quite possible for a dynamically-driven website using PHP and Mysql to be zippy. When I say zippy, something equivalent to the page loading of static HTML files (assuming the dynamically generated HTML and the static HTML are roughly the same size).

All features in software come at a cost. Drupal provides easy extensibility for non-programmers. Installing a module is typically as easy as downloading, moving it into a particular directory, then enabling it from the admin pages. But there are also costs associated with this. One cost is performance. Reading more lines of PHP takes longer than reading fewer lines of PHP.

Another cost is added complexity for simple modifications by a programmer. The architecture of Drupal is big; one should understand it before delving into customizations since you might expose a security hole by doing something you thought was simple. There's also the API. Do it the Drupal way but first you have to learn the API. Not to say that the API is difficult but you still need to confirm functions do what you expect. Of course, you can still do a mysqli_connect and mysqli_query directly but given that all these API functions are already being loaded, shouldn't you use them?

When you think about how many Drupal functions must be run in order for the results of a database query to appear onscreen, it's not difficult to understand why Drupal is not fast. Just thinking architecturally, an API database query is parsed/filtered and then run as a db specific query, the results of which are then pulled, squeezed and modified as necessary to meet the requirements of Drupal's core and installed modules, then the data is pushed through Drupal's theme engine until you see the final product onscreen. This is a gross simplication but I think you get the point.

The alternative to Drupal is to either use a lighter CMS or build something from scratch. Does a lighter CMS exist? In my experience going to Wordpress sites, those sites are not fast either (and often slower). Most open source CMS projects seem to go the same direction as Drupal: everyone wants a theme/templating engine, everyone wants easy-to-install modules, everyone wants an API. These goals are good for the project's sustainability but not necessarily best for a performance minded single site.

Starting from scratch is a nice thought but who has the time to build it from scratch? It's reinventing the wheel of something that has already been invented too many times to count. Go to Sourceforge and you can find literally hundreds of CMS projects, some active, some dead and some actively dying.

Although I can't say Drupal is fast, I think it's fast enough.