How to make OO code not bloated in PHP?

[lastcraft]

Hi...

Well, since it's past my bed time and I have all kinds of other work to do, I'm going to let this go for the most part.

You think you've got problems. Here it's 6am!! I really must stop reading sitepoint just before bedtime .

I agree that good design enables performance tuning, but is OO the only route to good design?

Nope. I mentioned other paradigms before which also have strengths. Procedural programming is crippling though and does a lot to inhibit design in larger systems (polymorphism and encapsulation again), so in practice I would say it is an inhibitor.

yours, Marcus

[Selkirk]

lastcraft, I agree that for the most part good design trumps performance. This is based on the idea that programmers time is expensive and computer time is cheap. Which it is.

Yet, there are cases where performance can and should be a issue. Those are when the cost of development can be amortized over a large number of potential users. I think this is the case for libraries and software that is meant for widespread distribution.

The economics change when you are doing a custom job for a single client or an inhouse program versus when you are doing a commercial program that might have thousands of users.

If your software has to compete in a market with many similar software packages, then performance can become part of the requirements for the software.

There was an interesting article a while back where they talked about how Apple's Safari browser development team made performance a goal and made it part of their testing regimen. They would not allow performance regressions and tested for them. When a programmer added a new feature, they were only allowed to add it if it did not cause the performance tests to fail. If it did, they were required to improve performance somewhere else in the program. Test driven performance development!

This is the model that I intended to follow for WACT and what I meant by Bloat test in this post.

Loads code that does not get used, loads data that does not get accessed, or performs calculations that do not contribute to the final product while servicing common or simple requests.

Implicit in this definition is the idea that simple things should be fast.

I've been using a performance benchmark as a proxy for bloat by taking advantage of the fact that parsing PHP takes time. Thus, smaller code should run faster in standard PHP. This is an experiment, really, and I've only been doing it since hearing about Safari development. I've liked the results so far. It will probably take me several months before I can form a definite opinion.

Does the fact that I am paying attention to performance mean that I am sacrificing good design? I hope not.

Perhaps my programming experience can help guide me not to make unwise tradeoffs.

One of the hypotheses of my experiment is that in interpreted PHP, a faster program has less code which indicates a better design. In other words, its not performance versus good design, but performance and good design.

regarding objects versus procedures, etc. I look at each as simply a way of organizing code. The fundamental idea behind objects is to minimize dependencies in the code. This is also the fundamental idea behind procedures. Other languages have additional organizational structures, like the unit in pascal. In PHP, the file could be considered an organizational structure of the language.

I think good design is about using the organizational tools you have at your disposal to organize code in a way that minimizes dependencies between organizational structures (changeable code) and that meets the requirements of the application, including performance goals.

[Dr Livingston]

... between organizational structures (changeable code) and that meets the requirements of the application, including performance goals.

Very good point The most difficult part IMO is how you plan and design your scripts to such a point where you can allow growth of your current application at a later date without sacrificing performance ?

This IMO is more down to how the class interfaces are built which is a stumbling block for a lot of folks as I see it ?

[nuncanada]

This is the model that I intended to follow for WACT and what I meant by Bloat test in this post.

...

Implicit in this definition is the idea that simple things should be fast.

I've been using a performance benchmark as a proxy for bloat by taking advantage of the fact that parsing PHP takes time. Thus, smaller code should run faster in standard PHP. This is an experiment, really, and I've only been doing it since hearing about Safari development. I've liked the results so far. It will probably take me several months before I can form a definite opinion.

I wonder how much of this is valid for big php applications...
We were having memory problems, so by cutting down how much code we're including we were able to make the mem usage go down severily with very little effort.
Still speed wise we didnt improve anything. It may be because of the extra include's needed instead of loading all the code at the same time.

Even then i would guess that for big php applications, code parsing time is not a big influence over the script execution time...

[Dr Livingston]

True...

[HarryF]

From way back

what sort of caching schema have you tried?

Now we're talking! Cache your queries, "compile" your HTML, using HTTP client side caching etc. etc. It's a great way to hide many evils.

This discussion seems to be going round in some circles.

Here's an opinion that's been forming in my brain for a while now, mostly triggered by Selkirk and looking at some of the design decisions that have gone on it WACT...

No one (I mean anywhere) has really defined what PHP actually is as a technology. Those from a C++/Java background bend it to their will, to do the same as they would in their compiled tongue. Those from a web design (HTML) background don't care. Those that have been programming with PHP for a long time know pretty much what it is by instinct but as an unformed idea, forget from time to time. Those working on the PHP source drop hints but don't explain.

Although PHP bears much similarity as a technology to many others, it has unique aspects which have a direct impact on design.

A simple example, as Selkirk has already said here, is if the first thing your app does in include 200+ class files (of which 3 are used) on each execution, the design is wrong.

Also, is starting with a database abstraction layer good design? Will your app be changing db provider between requests? Are you really prepared to avoid use the "good stuff" like MySQL's LIMIT clause in the name of one day being able to switch to Oracle? Use a class that's designed for a single database then, if your app really needs to support another DB, use an Adapter pattern to adapt say the PEAR:B or AdoDB library to your classes API [then worry about the db specific SQL...]. My guess is many people use db abstraction for the feel good factor.

On the subject or patterns, IMO they are a set of simple and down to earth ideas which, by becoming a subject unto themselves, have become some Mystic Force which either excites or terrifies. Really they're a vocabulary you can use to express yourself very precisely to another developer. For example above, I used the term "Adapter Pattern" to save me having to write a long paragraph describing what I mean. What did I mean? Simply writing a wrapper class or two around PEAR:B which gives me exactly the same API as my original class (so my code using the class can't tell the difference), allowing me to switch the database library with hopefully only a single line of code.

Back to caching - think design needs to consider this early as it's likely to be a critical element which will be pervasive throughout the app, if you want to implement it consistently. What's the fastest web page you know? Pure HTML... By "compiling" your HTML, only executing PHP code when something changes, your app can be almost as fast as pure HTML.

There are many such aspects of PHP that make it a unique technology, which generally manifest themselves in performance but are, IMO, design issues.

Otherwise check out XDebug (the extension works well on Windows and Linux now). The code profiling is an enlightening experience in many ways...

PS: Been on holiday and now playing catch up, hence recent silence.

[soapsud]

i'd have to agree, sorry for taking this slightly off topic, but i never really understood db abstraction. code run in the db is quite a bit faster, and more powerful than a generic framework built in the application layer.

given that data is the most important thing for most projects (ie, not talking about guestbooks here) you'll want most of the data integrity checks in the db (as it's faster and allows the app to focus on being an app)

as such, adding this intermediary layer to dumb down the db seems a bit silly, given that most projects will commit specifically to a database.

i'm definitely for using the adapter pattern though, to sanitize libraries which you're still not positive will make the final cut...

[lastcraft]

Hi.

The economics change when you are doing a custom job for a single client or an inhouse program versus when you are doing a commercial program that might have thousands of users.

Absolutely. It comes down to how much people time you want to waste, trading yours against the user(s) and how to trade best advantage. Unfortunately the medium of Sitepoint posts is a little limited, so I had to concentrate on a pretty well defined issue and environment . Also I am not advocating no optisation, just saying that it shouldn't be done in a way that is self defeating.

For libraries that you give to other people there is a commitment to optimise before release as your users will not be able to so easily. Their only option will be to change library. Even so other factors will probably swing people's decisions. A good tutorial will probably be worth more...

That said the time to do optimisation is the same. Once at the beginning to assess feasability (back of envelope usually) and then again later once you can measure that part of the system end to end. After that I guess whenever changes occour. The steps are tighter for shipped GUI apps (which I have done none of) I guess, but certainly the same for embeded systems which is more my background.

Test driven performance development!

It also fits with the idea that the application is ready to ship at any time. There are no hidden costs and any as yet unsolved problems are not committed to the current release. Not sure I want to try this system until I get some good reports from it, though. It is enough of a cognitive load to get the code correct and maintainable, without doing integrated optisation as well. Also optimisation in a web/LAN environment is very time consuming which could be a really draining at the unit test level.

This is an experiment,

And an interesting one.

There are also other positive benefits to optimising beyond the point of economic returns not yet mentioned. The feeling of quality and the morale boost it gives, but also the learning exercise. The hard facts that come back give a nice hefty dose of reality and understanding of how a system is really behaving. To me you win both ways.

How are you going to get the constant feedback about performance whilst you develop? Do you have a test scaffold that does page fetches? Should I be adding such a thing to (say) a web tester...?

I think good design is about using the organizational tools you have at your disposal to organize code in a way that minimizes dependencies between organizational structures (changeable code) and that meets the requirements of the application, including performance goals.

There seems to be a SitePoint pattern developing called "KillerLastParagraph" .

yours, Marcus

[Taoism]

Otherwise check out XDebug (the extension works well on Windows and Linux now). The code profiling is an enlightening experience in many ways...

PS: Been on holiday and now playing catch up, hence recent silence.

Welcome back!

This extension looks great! I love the profiling aspect of it. Unfortunately I haven't been able to get it to work yet, so I will have to keep trying to get it to run when I have more time...

Cheers,
Keith.

[HarryF]

This extension looks great! I love the profiling aspect of it. Unfortunately I haven't been able to get it to work yet, so I will have to keep trying to get it to run when I have more time...

You need to check PHP versions very carefully with what's stated on the site on the installation page (see table at bottom) . Also, on Windows, you may need to load it as a normal PHP extension rather than a Zend extension.

In php.ini I have (with PHP 4.3.2);

extension=xdebug-4.3.2-1.2.0-win32.dll

Probably this is subject for another thread.

The economics change when you are doing a custom job for a single client or an inhouse program versus when you are doing a commercial program that might have thousands of users.

Absolutely. It comes down to how much people time you want to waste, trading yours against the user(s) and how to trade best advantage. Unfortunately the medium of Sitepoint posts is a little limited, so I had to concentrate on a pretty well defined issue and environment . Also I am not advocating no optisation, just saying that it shouldn't be done in a way that is self defeating.

That's a fascinating discussion it itself, that we should kick off some time, as I don't see it critically analysed often. For example most of the work I do is Intranet related. I don't need to worry about economic issues much but there are design and technical issues which are very different to those when building an app to be exposed to the Internet, such as how to integrate with a wide range of existing LAN based systems, whether you should store data in a local database, etc. etc. while allowing you more leeway where performance is concerned. Just the subject of whether to authenticate against the existing LAN operating system (possible with both NT networks or LDAP based systems like Netware) is massive.

Would be interesting to spend some time really categorizing the different environments where PHP is used.

[BDKR]

Absolutely. It comes down to how much people time you want to waste, trading yours against the user(s) and how to trade best advantage. Unfortunately the medium of Sitepoint posts is a little limited, so I had to concentrate on a pretty well defined issue and environment . Also I am not advocating no optisation, just saying that it shouldn't be done in a way that is self defeating.

Nobody disagress with this (to a point). I don't either. What I should've tried to say in a more direct manner before is that nobody had spoken of optimisation until you brought it up. Not only did you do this (assume that we were talking about optimisation or even "going procedural") here, but you did it once over at the devnet forums as well. Nobody was talking about optimization thier either. That's why I said you have an axe to grind.

Anyways, the vast majority of us don't optimize up front anyways, nor should we. We build in accordance with a good desgin, then optimize should the need occur. Sometimes that involves architectural changes to the design itself.

We all know this.

However, there are some things we know up front that are going to behave or preform in a better/superior/faster manner. That said, do those things up front. Those aren't optimizations, which by definition means 'after the fact', but instead, they are design considerations and choices.

Which brings us to the next point, which is that should I decide to not use objects or only use some objects, the design does not have to suffer for it. People seem to forget that are some fantastic bodys of well used code that are written in a modular and extensible fashion without using objects. The Linux Kernel is a perfect example. The Quake engines are another example. Even Windows NT took this approch.

Despite its pervasive use of objects to represent shared system resources, Windows NT is not an object-oriented system in the strict sense. Most of the operating system code is written in C for protablility and because development tools are widely available. C does not directly support object-oriented constructs, such as dynamic binding fo data types, polymorphic functions, or class inheritance. Therefore, Windows NT's C-based implemantation of objects borrows from, but does not depend on, esoteric features of particular object-oriented languages.

That was from 'Inside Windows NT' by Helen Custer. It's old book, that much is true, but the NT/2000/XP kernel is still written in C.

This is taken from the faq at kernel.org

*Should the kernel use object-oriented programming techniques? Actually, it already does. The VFS (Virtual Filesystem Switch) is a prime example of object-oriented programming techniques. There are objects with public and private data, methods and inheritance. This just happens to be written in C. Another example of object-oriented programming is Xt (the X Intrinsics Toolkit), also written in C. What's important about object-oriented programming is the techniques, not the languages used.

This seems to be saying something that a lot of people in the PHP community should realize. That an object exists first at a conceptual level! How the implementation occurs is up to the developer or the team, not to mention the language involved and it's issues. Therefore, I can still realize a good OOD without using objects! Will it be a little tougher to deal with and maintain? Perhaps. However, will it perform better than using actual objects? There is a very, VERY good chance that it wll and there is plenty of proof to support as much.

So really, we should lay this idea that a good design isn't going to happen without the use of objects proper to rest. To say as much is simply wrong.

Cheers,
BDKR

[Dr Livingston]

One point that hasn't been put forwards is the advantage of OOP over and above Proc. Prog.

For example, you design your classes etc based on UML ? Now one PHP developer if skilled can understand the diagrams as such that they were drawn up from Java's use.

You cannot do that with Proc. Programming as I see it ? But I think this might be off topic some what since this is more of a portablitity issue maybe ?

[lastcraft]

Hi.

My instinct is not to reply to this as it's probably of marginal interest by now, but sadly I just cannot keep my finger off the mouse...

Not only did you do this (assume that we were talking about optimisation or even "going procedural") here, but you did it once over at the devnet forums as well. Nobody was talking about optimization their either.

Going procedural is the very first post of the thread. Yes I did bring up performance as one aspect of bloat to illustrate the point that developer time is the first priority and if one man's "bloat" cuts that time then good for them. I certainly wasn't the only person to mention it. I actually even think it was implicit in the first post.

..., which is that should I decide to not use objects or only use some objects, the design does not have to suffer for it.

We have had all of this before in the devnet thread. In all the examples you quote the designers have overlaid another paradigm (Objects for NT, domain language for Quake) over the procedural core. All you are doing with these examples is illustrating the inadaquacy of a pure procedural approach for any large project. Recreating an OO infrastructure is certainly possible in most languages, you could do it in PHP by keeping function names in hashes, but...
1) By doing so you would still be doing OO.
2) You would struggle to make it faster.
3) You would be wasting developer time which can be spent making things faster more effectively.

So really, we should lay this idea that a good design isn't going to happen without the use of objects proper to rest. To say as much is simply wrong.

I agree.

I haven't said that, though. I said "in practice" I feel procedural is an inhibitor. In fact most web projects I have worked on have had a mixture of paradigms: procedural (Bash/Perl), declarative (SQL), functional (XSLT), OO (PHP/Perl) and domain language (HTML/any config file). The purely procedural stuff has been relegated to housekeeping tasks, though.

I apologise for being overly tenacious at times (late night postings don't help).

yours, Marcus