I’m revisiting an older thread (PHP OOP makes slow application? [4037709]) on this subject (on the recommendation by this site due to its age being 14 months old) in order to shed some light on the subject of using an interpretive language in an Object Oriented fashion to render a stateless Web page. That’s three ways to slow down a Web server.
Compiled OOP languages, like C++ and Java, avoid much of their runtime inefficiencies by shifting that burden to compile time. Web pages written in JSP (Java Server Pages), for example, run fairly efficiently despite their OOP nature.
Then you take the nature of a stateless Web browser application. The Web server must render that same page every time it’s visited. The Web application must keep track of session information in order to maintain a seamless user experience. Techniques for storing and retrieving objects in a PHP session don’t appear to be any more efficient that of rebuilding them from a relational database. Since there’s no native way of storing session objects in PHP, methods for serializing them are employed to store them in a session that is ultimately stored on the server’s disk space. That adds complexity for storing, retrieving, and rebuilding the object later on that duplicates a simple database query. It also adds a level on inconsistency with the database if it is out-of-sync with the stored session object at time of retrieval (albeit maybe a desired feature; an object frozen in session time, for example).
My interest in this debate arises from an effort to teach myself PHP, MySQL, and Apache Web development using Joomla CMS. Having arrived at the point of mandatory source code modification, I’m using the Eclipse PDT to step through code and find that Joomla is quite object oriented. Using the Web server running on my ancient development machine (don’t laugh: P4 2.66GHz, 1G RAM), I can definitely tell where in the Joomla code my machine is struggling.
Joomla already in it infancy of version 1.5.15 has a reputation of being slow. While on the other hand, I come across discussions in forums about how one can increase speed microseconds by using one PHP primitive over another (obviously, not the OOP crowd).
In the earlier thread, there’s discussion about how OOP programmers observe rules of copious commenting in order for OO code to be re-used, and that the lack there of would defeat the purpose of choosing an object oriented approach to programming. Well, here’s an example from the base index.php page of Joomla:
/**
- CREATE THE APPLICATION
- NOTE :
*/
$mainframe =& JFactory::getApplication(‘site’);
/**
- INITIALISE THE APPLICATION
- NOTE :
*/
// set the language
$mainframe->initialise();
/**
- ROUTE THE APPLICATION
- NOTE :
*/
$mainframe->route();
/**
- DISPATCH THE APPLICATION
- NOTE :
*/
$option = JRequest::getCmd(‘option’);
$mainframe->dispatch($option);
/**
- RENDER THE APPLICATION
- NOTE :
*/
$mainframe->render();
Amazing! I couldn’t tell from the sparse comments that $mainframe->dispatch() was going to dispatch the application, especially not from the empty Note: comments. It would be nice to know what this student meant exactly by dispatch. Maybe he had intended to get around to filling in that comment fields after finishing his midterms. Or it simply could be that this student is suffering from college-on-the-brain and assumes that anyone worth his salt would obviously know what is meant by dispatch because he would’ve taken similar courses. I must be a lesser programmer, because I had to actually step through this entire author’s OOP PHP code to determine the difference between create, initialize, route, dispatch, and render.
In my search for vindication, I came across documentation that seems to justify my argument against using interpreted OOP in a Web-based application. Joomla’s nearest competitor, Drupal, appears to avoid OOP PHP and is significantly faster:
(Unfortunately, this site is not letting me post URLs, but this was taken from wiki’s drupal page.)
…Drupal’s Web pages were delivered “significantly faster” compared with Joomla.
Without personal experience using Drupal, I take it from this article that it avoids OOP:
(…and this from Drupal’s own site.)
Drupal programming from an object-oriented perspective
Drupal often gets criticized by newcomers who believe that object-oriented programming (OOP) is always the best way to design software architecture, and since they do not see the word “class” in the Drupal code, it must be inferior to other solutions. In fact, it is true that Drupal does not use many of the OOP features of PHP, but it is a mistake to think that the use of classes is synonymous with object-oriented design. This article will cover several of the features of Drupal from an object-oriented perspective, so programmers comfortable with that paradigm can begin to feel at home in the Drupal code base, and hopefully be able to choose the right tool for the job.
The point I’m trying to make is that when choosing the tools to do the job, to avoid the performance pitfall that software giants like Microsoft tend to fall into where they sacrifice software performance because computers always get faster. It took my using decade-old hardware as a development server to realize this application I’m developing wont to scale very well. Is that an acceptable tradeoff for OOP?
Please share your thoughts, opinions, and observations.