OOP vs Procedural

For most programmers, the answer is OOPs immediately. I think most programmers are wrong. Not in using OOPs but I think most programmers fail to actually look at what they are doing enough to decide between the two. Probably the biggest reason for this is that most programmers learn from a top down approach while I started with a computer engineering background had a bottom up approach. The reason today that it takes 1GB of ram just to boot Windows is from this very concept. Most programmers don’t really care or count the usage they are doing because they base their procedures on the Big O notation. Don’t get me wrong the time of Big O N squared compared to a Big O N algorithm is huge but most programmers don’t look into the difference within the nth notation of Big O time.

For example, a stock WordPress site such as this one makes roughly 8 SQL queries a page and accesses about 10-20 separate files in the framework. In a caching class we looked at the speed of L1 vs L2 vs Memory vs Disk Access times. Just looking at memory access time instead of cache will leave you wishing memory were faster by 100x. The truth is that you computer is often idling waiting for the disk, actually it switches threads and works on something else anytime it needs to access something on the disk. While accessing one file isn’t that big of a deal, most servers in real time load will make many calls to files and the more distributed your files are, the slower it will load. Now this is the time when people reply that, well the cache will hold it.  Your cache helps a lot, but by no stretch of the imagination does it help that much, even L2 or L3 cache is many cycles slower than your processor. Reducing your file dispersion will help shave a couple microseconds off your load time which in a production world means you server can handle more visitors. Lets admit that most web servers are overloaded, especially if you buy shared hosting. A server running solely wordpress could handle say 1000 visitors a second. When I build a custom CMS solution, it makes 2 SQL query and 4 file calls. That is 4x less than wordpress. In the world of big O, there is no difference in speed. Both are in order n. Yet if you ran a custom CMS you could handle 4,000 visitors a second while the wordpress could handle only 1,000 visitors a second. Granted the 4 less SQL and a couple less file calls doesn’t directly relate to 4x speed increase, it does highlight the point that Big O misses the difference. Developers need to start optimizing their code to be more efficient even when they don’t need to be. If wordpress was more efficient, people could run more sites on a single server, it would be faster, which leads to less demand on a single server, leading to less servers, leading to less power needs, less carbon, etc. Its a cycle and if we don’t start now with what little we can it will really never get anywhere.