Sub-theme vs base theme

...until you can audit a performance issue. The overhead of a subtheme is trivial compared to other operations (SQL queries for example).

You don't have a problem until you can identify a problem. Have you done any benchmarking? Is your site slow?

The theory behind a subtheme is this: You want to build a theme starting from an existing theme, but you don't want to hack the existing theme code. Sub-theming allows you to override templates and theme functions without changing the native theme code. You're basically just adding on to the original theme in a separate directory. That's it. The base theme's preprocessors and templates are invoked prior to any you define/override in your subtheme.

If leveraging the features of a base theme are useful to you, do it. If you don't find the leverage to be helpful, don't do it.

If the subtheme's base theme has terrible performance, your subtheme will inherit this terrible performance. If the subtheme's base theme has great performance, your subtheme will inherit this great performance.

If your subtheme you are building is doing something terrible on its own as a result of the code you are writing, that's your responsibility, just as it would be your responsibility if you were developing your own theme from scratch.

When building a subtheme, look at the base theme's template.php file and tpl's. See what they are doing. If they add unnecessary overhead in the preprocessors or do something you don't understand or need, it might not be worth leveraging the base theme in your subtheme.

But you could be "solving" a problem you don't actually have. Defining the problem is the first step of performance optimization. Optimization is top-down. You may find that your site is slow because you aren't implementing CSS spriting, or you have some costly third-party JavaScript, or you have a really malperformant SQL query.

Assuming you have other tools in place (APC, Drupal/Pressflow core cache, master/slave dbs, memcache, Varnish, Akami, CDNs) altering your own development practices are secondary. But performance optimization needs real data. If there are no metrics to compare, there is no defined problem.

thanks for all those answers, but actually "performance" was only a point, (I'm aware of Drupal probs, pressflow, CDN, memcache, sometimes heavy views queries etc ..)
To be totally honest, I usually used sub-theme which I found easier, but a customer order me a D7 theme (not an entire system as usual), and I was wondering if I would better deliver a "base theme" or a sub-theme, and specially if I go to "sub-theming" I will probably have to argue why I made that choice.

From my point of view, one advantage is to benefit from "structure" reflexion of several (hopefully good >;-) ) themer, disadvantage would be to have some uneccessary dom element (ex: footer,slogan etc if you don't need them), but from my point of view benefit are much larger & I'll probably propose that sub-theme approach even if from the customer point of view, it could look less "clean".

Since performance became an important topic here ;-) I agree that sprite technic give some good perf, but I always had to garanty (&%!!&%!!!) Ie6 compatbility ..once that dinosaur dead, life will be easier.
One big issue with css is the unused css inherited from the modules & system, like admin.css, view.css. ONe dream would be to have some king of "css compiler" that would cleverly regenerate a css, base on the produced & existing dom element, and that for each page .. but that will propably remain a dream ;_)
++,
marc

Hi

Yes there is a performance cost associated with subtheming, but then that's the nature of Drupal! Even a base theme is still overriding core CSS settings, and in the case of modules, you're changing the behaviour of core or existing modules rather than hacking them for the sake of performance.

You would probably only gain some minor performance improvement from creating a base theme. The main performance hit with sub-theming is downloading extra CSS files, however, this can be offset by aggregating CSS into one file, which the browser will then cache. (In D7 go to Performance and check "Aggregate and compress CSS files" - but only do this on production, not dev, as it hampers theming).

The other performance hit is at the browser end, where it builds an internal CSS file from its default CSS + Drupal core CSS + base theme CSS + your subtheme CSS. The speed to do this is fast in a modern browser, and I estimate the performance enhancement of removing one of those layers would be trivial compared with other factors such as network lag or database queries.

Have a look at YSlow if you want help speeding up your site, and, of course Drupal dev tools and especially query profiling.

HTH