Hi...
BDKR wrote:I feel that in a web environment, execution time takes precedence. I feel comfortable saying this becuase I know code reuse and a good clean design can be had without the use of objects.
On the small scale maybe, but I feel this is a little short term. You can get some reuse from functions, but you are always limited. With functions data is either global or you have to pass it around. Global data is the enemy of reuse, and yet passing and marshalling of data incurs an overhead. As applications get larger these two factors squeeze terribly.
OO brings the data and the functions closer together.
In functional languages you can pass functions around as easily as any data parameter, but PHP is not a functional language to this level (array_map excepted). If you want to move operations around they have to be bundled into objects in PHP. As the number of functions in your code goes up, the average distance that you have to move your data goes up in proportion. Any small efficiency you get from the simpler method dispatch is soon drowned by the extra method calls. With OO you pass less data.
Also "code-smithing" gives a very poor return on investment. If you need performance do you really un-OO your code? Hardly. More likely you introduce caching, use a faster data storage solution, white a C module or use lazy loading. These types of optimisations give order of magnitude improvements. Twiddling your code will give a few percent in all but exceptional cases.
So how easy is it to cache, lazy load, import a module or change database in a script/function based environment? I don't even intend to find out. From smaller scale projects alone I know that I can achieve it far faster with an OO code base.
An example? We were recently parsing a large number of web pages for a metacrawler and things were running a little slow (by about a factor of 100!). Our optimisations were...
1) Run the fetching with first a C, then a Perl solution with multiple processes as a separate module. It simply saves the results batch as a file. This gave us a factor of 20+.
2) Adding our own DNS server with it's own cache. This gave us 25% for very little extra effort.
3) Placing the temporary downloaded files into a RAM disk. Gave us a factor of two with nearly zero effort.
4) Caching the parsed search results in MySQL. This is the most work, but gives us a factor of 3+. DBM would give us more, but see below.
5) Now we were ready to profile we found that due to a bug, multiple hits were generating spurious method calls with empty results. A simple fix gave us 50% greater performance.
6) We found the next() call in the file iterators was the bottleneck because the fread() method takes too long. We created an iterator that loaded the file with a single next() with only about two dozen lines of code to write and one to change (we just had to drop in the new iterator). This gave us a factor of 2 with less than an hour's work.
7) Placing the main reusable cached data into MySQL allows us to access the cache over a network, which in turns mean there is no real state in the server. This allows us to have multiple servers load balanced sharing the same cache. We currently have three of these.
Doing more than about one of these refactorings in a functional version would have pushed us into a complete rewrite (with the exception of the DNS). With OO the impact was minimal and quick and allowed us to experiment and reprofile with ease.
What would you save with code smithing some thing this large? How much would you slow development? We never needed to hand optimise our code because we got a factor of 1300 times improvement by changing the design. We could do that easily because it was OO.
yours, Marcus.