Cleaning up WordPress to improve performance?

Looking over the current WordPress codebase it’s clear that functions are over-used. My count is over 8,100 functions/methods are defined inside the WordPress codebase. That is terrible, and a terrible use of resources.

The problem with that many functions (or classes) is that means wordpress is not DRY (do not repeat yourself) and I’m sure many of these blocks could be combined or replaced with better patterns.

However, we need someway to buffer the current API (all those functions) so we can begin to combine the backend code without the “interface” (used loosely) changing.

The solution?

PHP 5 & 6 has SPL Autoloading of classes. It’s a feature that allows PHP to wait until it needs a class before it load it. This prevents wasted resources as unused features/files are not loaded until they are needed.

Unfortunately, WordPress can’t use this because “autoloading” in PHP only works for classes.. and WordPress is a mountain of functions.

I am looking at options and challenges to cleaning up the WordPress codebase and this seems to be the biggest one.

Because WordPress has created so many functions (rather than exposing classes) for plugin/theme developers there seems to be no way to pull out of this deep hole without breaking thousands of themes & plugins.

The only idea I was able to come up with is to write a script that would look over all functions and convert them to classes which could then be autoloaded. In their place shell functions would be left that called the class-i-fied version of the function.

Something like this:

function wp_foo_bar() {
    call_user_func_array(array('foo' => __FUNCTION__), func_get_args());
}

Has anyone else tried to cleanup the WordPress codebase? Are there other problems with this approach?

Update to Clarify

Converting the system to use autoloading is the first step that allows us to gain better control of how resources are loaded and put up facades as we migrate some of the core features into better designs. It’s much harder to depreciate functions. Therefore, this question starts with the beginning re-write of the system.

If we stopped here – then we might have a net loss in performance because we have the same number of functions – and now classes are also beginning autoloaded.

Therefore, this has nothing to do with procedural code vs OOP. It’s about the best way to buffer the API against changes to the system as a whole. The current wordpress dev team is already doing this at a very slow pace. There are already over 60 classes in the wordpress system.

You are acting on awfully big assumption that something like that would improve performance. Spoiler — no, it won’t.

The load process in very loose terms consists of:

1. Optionally running code responsible for looking up definitions (autoload or custom).
2. Parsing the file or retrieving results from opcode cache.
3. Loading results to be used.

The “autoload is fast” is popular fallacy. Foremost autoload is convenient. It is can actually slow things down in practice because processing the files is hugely improved by opcode cache, but repeatedly locating those files (step 1) can only be optimized so far and adds up very fast.

Would WordPress core benefit from better organization and autoload of classes? Certainly, that is however not happening because it’s developed on premise of not using that feature of PHP.

But “converting” functions to autoloaded classes? My educated guess this would ruinous to performance, while trying to optimize part of process that isn’t bottle neck in first place (in current state of core code/load).