By Garrett Albright on

Apple's upcoming Mac OS X 10.6 "Snow Leopard" operating system update is notable in that its primary selling point to end users is that of increased speed and reduced disk usage instead of this new feature or that new feature or more eyecandy. There are new features, to be sure, but it's clear the focus of the update has been more around improving the OS X code base for the future instead of piling on new features. (To make such an update more palatable to end users, it's notable that Snow Leopard updates will only cost $30 instead of the $120 or so cost of previous updates.)

I think it would be wonderful to see Drupal take a similar tack for Drupal 8. Adding new features to core should take a back seat to improving Drupal's speed, ironing out persistent weirdness in the API, etc. Clearly Drupal is a feature-ful system, but with a core of this size, there's probably always going to be room for fundamental improvement there. My title for this thread was intentionally provocative and misleading - sure, D8 can have new features, but they shouldn't be a priority over speed and API improvements.

Maybe guidelines something like this can be set: The first priority is making page generation times for common tasks such as loading the front page, viewing a node with several comments, etc improve by at least, say, 20% over D7 speeds. Only then can new features be added, but only if they do not slow down the core enough to reduce the speed increase below that 20% (or whatever) level.

Your thoughts?

Comments

johnhanley’s picture

johnhanley commented

I couldn't agree with you more. I have serious performance concerns about D7... it's becoming too database-laden for my taste. Throwing more hardware at the application is not an acceptable answer. The focus for D8 should be optimization and restraint. I suspect our opinion will be in the minority though.

damien tournoud’s picture

damien tournoud commented

That sounds a little bit unfair for all the performance enhancement and API cleanups that got in during the Drupal 7 code cycle. To name a few: refactored session management, refactored page cache, a lot of optimizations along the critical page serving path, a lot of cleanups in the comment and the taxonomy module (that were desperately in need for attention), etc.

"No new feature" is a pipe dream. But if you want to lead an effort to improve and clean-up the existing APIs, you are more then welcome!

Garrett Albright’s picture

Garrett Albright commented

By no means am I disparaging the code improvements made in D7. In fact, I'm saying I want more such improvements, more so than I want new features!

And, yes, perhaps I should put my money where my mouth is and get more involved with core hacking personally. But it's tough to find the time to keep track of all the stuff that's happening to core; I can't help but wonder how so many other people can do it…

extde’s picture

extde commented

How could I work with Drupal 6 and 5 after 7 was released?
New version (7) is much better than 6.
However, closer look to system.module shows - it still needs a lot of work.