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.

  • 5
    Have you ever tried to write a program in C or Haskell? Some of the fastest programs are entirely procedural
    – Tom J Nowell
    Sep 3, 2014 at 22:04
  • 6
    Is this a rant or an honest question? Sep 4, 2014 at 7:00
  • @JohannesPille, this is an honest question. I have already begun research and work on this approach.
    – Xeoncross
    Sep 4, 2014 at 14:22
  • 4
    So you are going to rewrite the entire WordPress code base? I wish you all the best to stay sane and good luck! Sep 4, 2014 at 15:25
  • 2
    Oh, I didn't take it as an insult. My comment said that I plan on having the computer rewrite it for me. I don't think I would be able to handle rewriting the system by hand.
    – Xeoncross
    Sep 4, 2014 at 15:42

4 Answers 4


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).

  • This answer gives people the wrong idea. I clarified my question to help explain that this is simply the first step in cleaning up the system. First you need resource conscience loader and some facades to mask the changes you plan on making. In addition, converting a system to use autoloading reduces speed but saves memory which is what Wordpress has the biggest problem with. Even reading from an OP Cache PHP still has to load the data structure into memory and flush it each page request.
    – Xeoncross
    Sep 4, 2014 at 14:23
  • 1
    @Xeoncross my current dev install shows about 3 megabytes of memory consumed for basic pageview (admin or front either). I would never sacrifice load speed to try reduce WP memory usage, it sounds like horrible tradeoff (in my opinion and for current state of code).
    – Rarst
    Sep 4, 2014 at 14:51
  • Well, performance at a large scale is about more than just saving .08 seconds of load time. If the memory can be reduced by even 1/2 MB then we can serve just under 15% more visitors. I have done a lot of tuning to wordpress sites that get hundreds of visitors a second and this would be a major win.
    – Xeoncross
    Sep 4, 2014 at 15:12
  • 3
    @Xeoncross you might have a point for your specific circumstances, but I have doubts about cost–effectiveness of "enough development time to rewrite WordPress core" against "add more memory to server".
    – Rarst
    Sep 4, 2014 at 15:36
  • 1
    For a single team you have a point. (Hence why no one has rewritten it). However, Open source development as a whole could be looked at that way - just a waste of time when you could be making money doing something you are payed to do. Wordpress is used by millions of sites around the world. Fixing core memory issues would result in millions of dollars of relief for companies around the world. It certainly is a big task, one that may not even be possible if we hope to achieve backwards compatibility (look at ghost).
    – Xeoncross
    Sep 4, 2014 at 15:40

functional interpreted code will always be faster then OOP one. Compare

function hello_mark() {
  echo 'hello mark';



class mark {
  function say_hi() {
    echo 'hello mark';

$m = new mark();

I think it is obvious what is faster to interpret and execute.

People don't do OOP because it is faster, they do it because it represents better the "problem domain" and produces easier to maintain code.

The code supposed to be organized in a way in which it will be easier to maintain and develop, for speed to can always use better interpreters, or compile to machine code or like Facebook's hiphop reduce the features of the language you are supporting and integrate a web server into your interpreter.

Specifically for wordpress the thing that influences the most the speed of the site is the quality of caching that is being used. No improvement in the php code will get you the same performance boost as utilizing object caching.

Anyway, just because there are many functions that are not lazy loaded doesn't mean that even under lazy loading they will not be loaded by the time wordpress finishes its initialization. give some credit to the core developers to know the language good enough to be able to put functions which are not needed for the initialization at their own files whenever it doesn't break the logical structure of the software (ie it will be stupid to put update_option in a different file then delete_option just because delete_option is not called during initialization)

  • I think you misunderstand my approach. Wordpress is needlessly slow, mostly because of the design approach to the system as a whole. However, before we can clean up certain parts of the system we need to build a "facade" in front of the current exposed API (all those functions) so that we can begin to refactor them without breaking existing plugins and themes. This is not about OOP vs procedural - this is about DRY, DI, and convention over configuration. If we could accomplish this with functions I would be all for it.
    – Xeoncross
    Sep 4, 2014 at 15:23
  • IIRC 23% of the internet sites owners disagree with your assertion that wordpress is slow. It doesn't matter at all for them if it can be made faster as it is already fast enough for them. If you want raw speed and resource optimization then php (or any other interpreted lang) is the wrong choice and you should code your CMS in C. Speed of a CMS is totally irrelevant as CMS 99% of the time don't do anything if you have a full page caching, so why to ruin the architecture of the software in order to achieve insignificant improvement for the 1% of the time in which the CMS actually do something? Sep 4, 2014 at 19:29
  • "Speed of a CMS is totally irrelevant as CMS 99% of the time don't do anything if you have a full page caching" Who said anything about speed? I am going for performance which mostly involves the memory usage of Wordpress. Even full page caching still loads the whole wordpress system to figure out what to do.
    – Xeoncross
    Sep 4, 2014 at 19:36
  • memory in all kinds of software has nothing to do with the style and organization of the code. to process a 50k byte size image you will need more then 50k byte memory. Memory consumption is related to the quality of your algorithms not your coding style. Sep 5, 2014 at 5:56
  • I agree. I'm not sure why you think I was saying different. The point of this reorganization is simply to provide a buffer between the developer and the core system so that better algorithms (or design patterns) can be chosen. If you know how to do that without reorganizing the code then please speak up.
    – Xeoncross
    Sep 5, 2014 at 14:21

Best of luck to you, but this won't improve performance in any real way.

WordPress is indeed becoming more and more object oriented, over time and with incremental changes. Every update in the last 4 years has refactored some major piece of code into a more class oriented design.

Nevertheless, OO and autoload and other things like this are not inherently "faster" nor are they actually "better". No worries though, this is a common fallacy.

OOP in general is a different way of organization in programming. It's a saner, cleaner approach for a lot of cases. But it's not inherently "better", and it's actually notably slower and more memory intensive in almost all real-world scenarios, or at best it's break even. The OOP model is generally preferred because a) it's easier for maintenance and code-testing, b) it's taught in a lot of schools as the "correct" way, and c) programmers are the kind of people who like to build models of things. OOP fits well with that "model" mentality. Represent a "thing" using a single piece of code, then have your "things" interact with other "things" like fitting lego pieces together. Neat, clean, tidy. :)

The truth is that with things like opcode caching, autoload provides virtually no speed benefits, just organizational ones. And don't get me wrong, a benefit is a benefit and better organization is a good thing. But you get better organization through organizing stuff, not through automated processes.

Can you write code to move all the code into classes and then make the functions mere hooks into those classes? Sure, probably. What will it help? Nothing of substance.

To address your specific desires:

It's much harder to depreciate functions Therefore, this question starts with the beginning re-write of the system.

First, I think you meant "deprecate".

Secondly, you can't rewrite the whole thing at once and achieve your goals. That's sort of my whole point. Go back and look at 3.1 or 3.2. Now look at 4.0. Note the number of classes and the way that they are indeed being refactored over time.

It makes no sense to spend a bunch of time rewriting working code only to end up with the same results, unless you're going to actually improve it in the process. As each piece in WordPress gets improved, it usually gets modified into a class/OOP system. Gradual evolution. Change over time, to allow old plugins to die off and new code to be created to support it and get fixed and such. You can't break the world overnight and expect everybody to follow along, you have to change things slowly and methodically.

  • "OO and autoload and other things like this are not inherently 'faster' nor are they actually 'better'. No worries though, this is a common fallacy." I never, anywhere claim this fallacy and have tried to clarify this multiple times already. However, while your last paragraph is certainly true - the gradual evolution is something I've been waiting years for. I'm ready to try my own hand at it and was looking for feedback on design problems with the approach. Whether what I hope to achieve is likely to happen remains to be seen.
    – Xeoncross
    Sep 4, 2014 at 17:47
  • Xeoncross: Your question itself straight up talks about "performance" in the first sentence. Then you go on to talk about OOP and autoloading and classes and such, none of which impact performance. You're having to repeatedly clarify yourself because your question simply implies that you don't understand this sort of thing. If you are not talking about "faster" or "better" then don't use the word "performance".
    – Otto
    Sep 4, 2014 at 22:11
  • 3
    Huh. As a professional developer for 15 years, I'm slightly offended by that.
    – Otto
    Sep 5, 2014 at 15:29
  • 1
    I'm sorry man. I don't mean to be rude. I'm just perplexed by how simplistic the answers and replies are. I get the feeling no one here has actually built non-wp-apps before or worked in a language other than PHP. Perhaps I need to learn to communicate better, or put a large list of I'm not talking about... at the bottom of my post.
    – Xeoncross
    Sep 5, 2014 at 16:48
  • 1
    I've programmed in Java, C, C++, PHP, Perl, Python, various flavors of shell scripting, and yea, even back unto C64 Basic and ASM when I was a kid 30-odd years ago. It's not a question of experience, it's a question of communication. Clearly your original question implies that you think object oriented programming is faster, better, stronger, something like that. I'm sorry that you feel that you need to explain yourself so many times, but the truth is that if this is the case, perhaps the question (or underlying idea) itself is unclear, and this is not the fault of the people reading it.
    – Otto
    Sep 5, 2014 at 17:56


You write in your WP Dev profile

You may notice that some of my questions run very deep into the heart of certain issues because I strive for the highest optimization that is possible in my apps.

That's all well and good for an App, your App or an App that you're working on; or your own programming philosophy and techniques.

But Wordpress is a community, and as such works differently. It may sacrifice (for lack of a better word) things in terms of programing structures, languages and efficiency that are priorities with small or individual projects.

But Wordpress gains much as a result of being a community. The ecosystem is large and varied, the development rolls along, and as a result - or in spite of - WordPress is very popular.

As a community, Wordpress can't assumed to act as the same way an individual project or dev might work.

You're comparing apples and oranges, as well as the trees they grow on and the people who like apples better than oranges.

I don't consider myself a programmer, and I can't argue the benefits and merits of OOP, classes, procedurals, and on and on.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.