That sounds impressive, and I don’t doubt your competence, however, I would be willing to bet there are tons of C-developers who would take you to task on that point!!!
Haha I’m sure there would be. Although they have two disadvantages:
-
They tend to focus on implementation details rather interface, sacraficing code clarity for optimization (ie: http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html). I’m pretty there is a similar article with Linus touting performance and procedural programming.
-
C developers are accustomed to tweaking code in esoteric ways to squeeze performance out of every line (I did it myself 10+ years ago). You cannot perform the same optimizations in php.
It’s a practically impossible challenge but would be interesitng none-the-less. 
(So does that mean that an OOP-newbie like me should give up before I start on building an OOP e-commerce site?!)
If you give up, you would never learn, so obviously the answer is no. Your understanding of software design is like a software system itself. Constantly changing, improving hopefully, even though sometimes, software gets worse before it gets better. Absolutely build a eCommerce site, share it if you want, I download and play with every application I encounter. I probably have half of sourceforge on my local HDD 
So poor database design and/or poor database optimizations (e.g. indexing) is MORE of a factor than “bloated” OOP code? (Assuming the OOP code is indeed “bloated”?!)
Personally, I think thats a myth or simply not true with most applications. Yes SQL accounts for some lag, if your tables have 500K records and your SQL SELECT is something like:
SELECT * FROM
(
SELECT * FROM table1, table2, table3 WHERE t1.id = t2.id AND t3.id = t2.id
) AS t4
WHERE first_name LIKE ‘Test%’
- Using JOINs (I believe) is faster/optimized compared to relating the tables in the WHERE clause
- If first_name is not indexed or the ID’s then performance will really degrade
- Obviously the sub-select is not required and extraneous and will probably affect performance.
That being said, most application developers don’t understand SQL well enough to write overly complicated SQL. Most just stick with CRUD-S operations and perform the rest in PHP logic. Complicated business logic (desperate for refactoring) can also account for a lot of clock cycles, IMO.
I just remember one big dig against Java - and thus maybe OOP - is how clunky Java is when used on the front-end GUI. (I’ve actually seen this in real life with things like IDE’s written in Java (e.g. Eclipse) versus IDE’s written in something like C (e.g. _____).
Funny you mention that, I use Eclipse.
It is bloated and slow, not just because of OOP but JVM and cross-platform support. You can look at C/C++ editors which compile differently and use the OS native API instead of it’s own. Qt I think compiles to a native binary, resulting in the same benefits of abstraction (cross platform portability anyways) but still run faster because the middle man is cut out at pre-compilation (preprocessing I think), whereas Java stays.
Eclipse is really slow though and buggy in many ways, but it’s extensibility and incredible feature set is like no other IDE I have ever used, so I put up with it.
But isn’t it supposed to be optimized for the web and thus faster, or am I confusing that statement with MySQL?!
I think you confusing developer performance with execution performance. PHP is designed for the web, at least the Apache module version. Embedded HTML and PHP is it’s greatest strength and at times weakness. It lets you hammer out dynamic web pages fast, but without care or inexperience can result in one hell of a maintenance nightmare.
PHP 5 seems to have great strides in the OO world, but there are a lot of people that feel Procedural code is more straight-forward, requires less lines of code to do the same thing, and thus offers better performance (even if it may be harder to maintain).
Some languge features prevent you from shooting yourself in the foot in some situations and make your code worse in others. Access control for instance (private, public, protected). Sometimes, very rarely (IMO) methods of a function should just not be exposed to client developers, using private or protected accordingly just makes sense.
In many of these cases, what would be more effective, is a lambda function, but prior to closures, this often resulted in horribly hard to read code, so a private method often did the trick and sometimes results in more re-usability within that class.
Whether code is straight forward or not, again, has less to do with OOP VS Procedural and more the experience and desire of the original author. Some highly experienced programmers just deal with complexity better than others. I hate details, I don’t want to think about the code I’m writing, I want it to read like natural english, so I strive very hard to write code that reads as good as it runs. I avoid comments like the plague, except to make terse callouts of potential odd behavior, side effects, etc. And I scatter my code with TODO: so I can easily grep them out and print them for daily tasks lists.
was just wondering PHP and OOP could be a bottle neck or a place that leads to what is going on at work (in general terms).
Not a bottleneck, unless it’s done poorly (notice I refrained from bad; cause any code that runs and works can’t be bad). Hire a outside OO architect to consult your team if you are not comfortable enough. You write the code, busines logic, etc, the consultant would just steer you in the right direction, perform daily code analysis, make suggestions, then you decide whether you make those changes, based on the repercussions he/she has provided you.
@TomB - sure OOP is slower - but how much? Seconds, minutes, days?
Well, I cannot say with any great conviction, but if I were to hypothesize:
- Maintaining a v-table
- Deferencing the this pointer
Comparing the function invocation of a function to a method, the difference is microseconds, probably. But if a function takes 0.0005 seconds to invoke and a method takes 0.0010 seconds to invoke, thats twice the performance. The difference is really only a problem, when you take a single core processor and call the two 100K times side by side. Obviously if the function takes 5 seconds, the method should take around 10 to complete. But how many useful programs consist of a single function called 100K times? None that I know of.
Applicaitons consist of layers upon layers of code, each layer acting as some kind of abstraction or interface to the layer above it (hopefully).
OOP lends itself to solving this better in the grand scheme of things, than procedural.
I guess my opinion, is simply that, if all developers realize the benefit of abstraction (no PHP program i know of communicates directly with the kernel or hardware, at best you’d go through drivers; and probably some higher level API) and accept the importance of abstract interfaces, layers, etc, then why not try an achieve abstract implementations, which is easier to achieve in OO than it is with procedural programming.
If speed is a concern why are you using PHP in the first place
Bingo. Write PHP and use that facebook PHP compiler.
Cheers,
Alex
