I used to use procedural-style PHP. Later, I used to create some classes. Later, I learned Zend Framework and started to program in OOP style. Now my programs are based on my own framework (with elements of cms, but without any design in framework), which is built on the top of the Zend Framework.
Now it consists of lots classes. But the more I program, more I'm afraid. I'm afraid that my program will be slow because of them I'm afraid to add every another one class which can help me to develop but can slow the application.
All I know is that including lots of files slows application (using eAccelerator + gathering all the code in one file can speed up application 20 times!), but I have no idea if creating new classes and objects slows PHP by itself.
Does anyone have any information about it?
This bugs me. See...procedural code is not always spaghetti code, yet the OOP fanboys always presume that it is. I've written several procedural based web apps as well as an IRC services daemon in PHP. Amazingly, it seems to outperform most of the other ones that are out there and editing it is super easy. One of my friends who generally does OOP took a look at it and said "no code has the right to be this clean"
Conversely, I wrote my own PHP framework (out of boredom) and it was done in a purely OOP manner.
A good programmer can write great procedural code without the overhead classes bring. A bad programmer who uses OOP will always write crappy OOP code that slows things down.
There is no one right answer to which is better for PHP, but rather which is better for the exact scenario.
Here's good article discussing the issue. I also have seen some anecdotal bench-marks that will put OOP PHP overhead at 10-15%
Personally I think OOP is better choice since at the end it may perform better just because it probably was better designed and thought through. Procedural code tends to be messy and hard to maintain. So at the end - it has to be how critical is performance difference for your app vs. ability to maintain, extend and simply comprehend
The most important thing to remember is, design first, optimize later. A better design, which is more maintainable, is better than spaghetti code. Otherwise, you might as well write your web app in assembler. After you're done, you can profile (instead of guess), and optimize what seems slowest.
Yes, every include makes your program slower, but there is more to it than that.
If you decompose your program, over many files, there is a point where you're including/parsing/executing the least amount of code, vs the overhead of including all those files.
Furthermore, having lots of files with little code ain't so bad, because, as you said, using things like eAccelerator, or APC, is a trivial way to get a crap ton of performance back. At the same time you get, if you believe in them, all the wonderful benefits of having and Object Oriented code base.
Also, slow on a per request basis != not scalable.
Updated
As requested, PHP is still faster at straight up array manipulation than it is classes. I vaguely remember the doctrine ORM project, and someone comparing hydration of arrays versus objects, and the arrays came out faster. It's not an order of magnitude, it is noticable, however -- this is in french, but the code and results are completely understandable.. Just a note, that doctrine uses magic methods __get, and __set a lot, and these are also slower than an explicit variable access, part of doctrine's object hydration slowness could be attributed to that, so I would treat it as a worst case scenario. Lastly, even if you're using arrays, if you have to do a lot of moving around in memory, or tonnes of tests, such as isset, or functions like 'in_array' (it's order N), you'll screw the performance benefits. Also remember that objects are just arrays underneath, the interpreter just treats them as a special. I would, personally, favour better code than a small performance increase, you'll get more benefit from having smarter algorithms.
If your project contains many files and due to the nature of PHP's file access checking and restrictions, I'd recommend to turn on realpath_cache, bump up the configuration settings to reasonable numbers, and turn off open_basedir and safe_mode. Ensure to use PHP-FPM or SuExec to run the php process under a user id which is restricted to the document root to get back the security one usually gains from open_basedir and/or safe_mode.
Here are a few pointers why this is a performance gain:
https://bugs.php.net/bug.php?id=46965
http://nirlevy.blogspot.de/2009/01/slow-lstat-slow-php-slow-drupal.html
Also consider my comment on the answer from #Ólafur:
I found especially auto-loading to be the biggest slow down. PHP is extremely slow for directory lookup and file open access, the more PHP function you use during a custom auto-loader, the bigger the slow-down. You can help it a bit with turning off safe-mode (deprecated anyways) or even open-basedir (but I would not do that), but the biggest improvement comes from not using auto-loading and simply use "require_once" with complete fs pathes to require all dependencies per php file you use.
Using large frameworks for web apps that actually do not require so large number of classes for everything is probably the worst problem that many are not aware of. Strip it down at least not to include every bit of code, keep just what you need and throw the rest.
If you're using include_once() then you are causing an unnecessary slowdown, regardless of OOP design or not.
OOP will add an overhead to your code but I will bet that you will never notice it.
You may reconsider to rethink your classes structure and how do you implement them. If you said that OOP is slower you may have to redesign your classes and how do you implement them. A class is just a template of an object, any bad designed method affects all the objects of that class.
Use inheritance and polimorfism the most you can, this will effectively reduce the amount of behaviors and independent methods your classes need, but first off all you need to create a good inheritance map, abstracting your first or mother classes as much as you can.
It is not a problem about how many classes do you have, the problem is how many methods, properties or fields they have and how well are those methods structured. Inheritance reduces the amount of methods to design drammatically and the amount of code to be compiled too.
As several other people have pointed out, there is a mild overhead to OO PHP, but you can offset it by focusing your optimization effort on the core classes that your various other classes derive from. This is why C++ is becoming increasingly popular in the world of high-performance computing, traditionally the realm of C and Fortran.
Personally, I've never seen a PHP server that was CPU-constrained. Check your RAM use (you can optimize the core classes for this as well) and make sure you're not making unnecessary database calls, which are orders of magnitude more expensive than any extra CPU work you're doing.
If you design a huge OOP object hog, that does everything rather than doing functional decomposition to various classes, you will obviously fill up the memory with useless ballast code. Also, with a slow framework you will not make a simply hello World any fast. I noticed it is a kind trend (bad habit) that for one single facebook icon, people include a hole awesome font library and then next there is a search icon with fontello included. Each time they accomplish something unusual, they connect an entire framework. If you want to create a fast loading oop app use one framework only like zephir-phalcon or whatever you fancy and stick to it.
There are ways to limit the penalty from the include_once entries, and that's by having functions declared in the 'include_once' file that themselves have their code content in an 'include' statement. This will load your library of code, but only those functions actually being used will load code as it is needed. You take a second file system hit for the included code, but memory usages drop to practically nothing for the library itself, and only the code used by your program gets loaded. The hit from the second file system access can be mitigated by caching. When dealing with a large project of procedural based PHP, this provides low memory usage and fast processing. DO NOT do this with classes. This would be for a production instance, a development server will show all the penalty of hits since you don't want caching turned on.
Related
I DON'T WANT TO COMPILE PHP TO NATIVE EXES OR ANYTHING LIKE THAT, ONLY COMPILE/CACHE (both words don't reflect what I mean) THE FRAMEWORK LOGIC ITSELF
Is there anything like a compiled PHP Framework?
What I mean is take Kohana as an example. It's extensible, overrideable, fun, etc. But it ends up loading 200 files to show one page!
What I would think is best is if you have Controller_Admin extends Controller_Admin_Template extends Controller_Template extends Kohana_Controller_Template extends Controller extends Kohana_Controller. This isn't needed... if we just copypasted method bodies to $parent->whatever() it would end up in one nice, smaller, faster file.
We already do it for JS and CSS to minimise assets downloaded; why not the whole framework? :D
Also I am looking for a compileable ORM. The Kohana ORM is very... slow... it uses magic methods, loads tables, generally is fun to work with but a pain in the... circuitry of the server. :P
If we could make ORM::factory('test')->compiled()->where('bla','=','1)->execute(); to compile into ORMC::factory('test','SELECT * FROM test WHERE bla=1')->execute(); in the production server it would be cool. This applies to a bunch of other stuff besides ORM but ORM would benefit greatly.
The overhead of dynamic frameworks doesn't seem to tip the scales by the ease of use in my opinion. With this we lose no ease and speed it up a lot. ;)
So my question is: Does something like this exist? If not, is my logic flawed?
Edit:
Because of failed answers I'll show more straight what I want to do.
We have an /application/ where there is the EXACT SAME code as without "compiling", and a /compiled_app/ where all (for example) queries that can be SIMPLIFIED are SIMPLIFIED (not object Query_Builder but SELECT blablablabla etc).
Also as much as having 50 files for one class adds a lot of umm... override vectors? :D it is an UNNEEDED 100% GUARANTEED BOTTLENECK PERFORMANCE OVERHEAD. Maybe it's not much but it's there always. And it doesn't have to.
You can check Flow3 framework and how it works. Its not really what you want but maybe you will find it interesting..
PHP is an interpreted language and doesn't compile as such.
There is APC which dynamically compiles PHP code into the bytecode that the Zend engine executes and caches it. This can gain you quite a bit of performance but it has drawbacks and limitations.
Honestly though, what you're asking for sounds an awful lot like premature optimization. The biggest factor in deciding how fast your code will run is choice of algorithm. A compiled bubble sort on a million records is still going to be slower than an uncompiled quicksort on the same number of records. PHP apps also tend to spend a lot of time communicating with external systems such as databases. You can't optimize this kind activity at all by compiling the PHP. A query that takes 10 seconds is going to take 10 seconds whether the PHP is compiled or not.
If you are having performance issues with your application then the SQL queries it's executing is usually a good place to start when it comes to optimizing. A lot of PHP code does too much querying, executes queries in loops, or queries for data that the application subsequently does nothing with. Finding and eliminating these will speed your application up no end.
However, it's important to note that you should never try to optimize your code by guessing at where the bottlenecks are. Use a tool like XDebug to generate a profile of your running code and then analyse he output to determine where the hot spots in your code are.
Most importantly, if you're not having performance problems then optimizing for its own sake is a waste of time. Premature optimization wastes developer time, it tends to make source code less readable and harder to maintain, and it has a tendency to introduce bugs. Only optimize when there is a proven need for it.
You can check Yaf. It's a framework compiled to PHP extension.
Have You ever heard about HipHop? It can compile whole PHP application into one binary file.
I know there are countless questions about the difference between OOP and procedural, when to use either and whether the benefits outweigh the extra overhead, learning the syntax, inheritance confusion, etc. Most of what I've found tends to just discuss differences and benefits and not whether its necessary.
I generally mix OOP and procedural within the same sites scripts depending on what I'm doing. I'm still fairly new to OOP and actually quite like the modular nature of OOP and the benefits it gives, even if there's a minor overhead. Inheritance can get a little confusing at times though!
To me the major benefits only seem to be in better organisation and protection of the code. Of which, the developer or team of developers are the only people to appreciate it. I guess there's a case for deployment speed but wouldn't say there's a lot in it for most sites unless you've inherited someone else's birdsnest :)
Is OOP necessary in most PHP apps though, especially when execution speed is the holy grail for most sites? ok, so the milliseconds overhead won't really notice unless a heavy use site but as a fan of electronic music speed is king!
I get using OOP in complex things like gaming and real-time cloud software, but static websites? even database heavy ones?
Does anyone have real world examples of typical sites that benefit from OOP and why?
Assuming both cases are well structured, would heavy use sites like ebay or monster.co.uk benefit more from OOP or the speed improvement of procedural ()? and why?
At least with procedural you can debug from the top down without having to bounce around the script to check classes and extensions and interfaces.
Can't I just apply OOP modular thinking with clear MVC and well commented code?
For example, I keep re-usable functions in include files and group related functions together. All I have to do is include the file like I would a class file and call up the functions. If the function needs to change, it gets changed in just one place, similar to a class.
And a kind of inheritance already exists in procedural without having to jump through hoops to declare it. You don't have the same level of control but it gets the job done nice and quick.
You could even simulate a class by grouping functions within a parent function and use a selector function to access them. That's taking it a bit far though!
Also, as far as I'm aware when a function is called it stays in memory making subsequent uses quicker. Whereas with OOP you would have to create two objects of the various methods to use the same function for two different variables. Correct me if I'm wrong.
Why create an object and use a method to 'get' a value when I could just reference the value directly with procedural?
well done for getting this far, hadn't realised I'd typed so much. Anyway, before I digress any further I'm going to end it here.
So if you've got any good examples of actual sites or parts of sites that benefit from either OOP or procedural I would really appreciate the clarity.
People managed to write good, clear, well organized code long before OO languages became popular. I see no reason why it can't still be done now.
Generally OO principles make it easier (which is one reason why OO is so popular) but they are by no means a necessity.
There are lots of questions here. I recall writing a long essay addressing some of these points while at university, but I don't want to reproduce something similar here, so instead, let me share a few thoughts:
Is OOP necessary in most PHP apps though, especially when execution speed is the holy grail for most sites? ok, so the miliseconds overhead won't really notice unless a heavy use site but as a fan of electronic music speed is king!
I think that if execution speed is a really big deal for you, php is not the right language for your website. Compared to the large performance cost of using an interpreted language, a little overhead is negligiable compared to the advantages of the OOP programming style for creating large systems. Do not discount the importance of making something easy for programmers to do, as this means faster releases, less bugs, and more maintainable code.
I get using OOP in complex things like gaming and real-time cloud software, but static websites? even database heavy ones?
I agree with you here. A nice thing about websites is that they are naturally modular because they are separated into pages. It hard to write code so bad that future programmers can't maintain it (for a fairly simple, static website).
For example, I keep re-usable functions in include files and group related functions together. All I have to do is include the file like I would a class file and call up the functions. If the function needs to change, it gets changed in just one place, similar to a class.
You can write good procedural code, but its harder than writing good OOP code. Weaker programmers are less likely to write insane spagetti code when given an OOP system to work with.
Why create an object and use a method to 'get' a value when I could just reference the value directly with procedural?
This is your only real implemenation question. The idea with Getters/Setters is so that you can change the internal workings of the class without breaking other code that depends on it.
I get using OOP in complex things like gaming and real-time cloud software, but static websites? even database heavy ones?
Implying that you don't want speed in games but want speed in websites.
PHP is never the bottleneck, if it is, write it in C.
Don't write procedural code because it is "faster". That's silly.
Does anyone have real world examples of typical sites that benefit from OOP and why?
Websites benefit from modular code that is maintainable and well organized.
You don't need OO for this, you can do it with functional or imperative styles. However PHP is known for it's ease to write bad code in a procedural style.
I would personally say that it's more likely your code is modular and maintainable if it was OO.
It's not necessary though.
And a kind of inheritance already exists in procedural without having to jump through hoops to declare it. You don't have the same level of control but it gets the job done nice and quick.
In OO programming it's all about encapsulation which means binding a lump of data to some functions that manipulate it.
You can do this just as well with a set of functions which take a data object as the first argument or classes.
Classes and OO just gives you sugar and utility.
It's a tool to write modular code, if it's helps you use it.
Don't pre maturely optimize OO away because it's "slow". If you care about that kind of micro optimization then start writing C or ASM.
I think a lot of people who promote OO are younger and have only ever written/been taught OO and so have a very negative view of procedural as old fashioned and 'legacy'.
IMO it is easy to write modular procedural PHP that is DRY and can be easily maintained. The trick is to use functions and 'include' to reuse standard php and html respectively. At the end of the day PHP is just reading DBs and generating html - there is no specific need to add the extra complexity of OO if you don't want to.
I was asked to do a project in PHP and to make sure it was object oriented. I've done OO and I've done PHP, but never both.
The main benefit of OO PHP (outside of inheritance/polymorphism) seems to be code organization. That's fine; I'm doing that. But where I get stuck is if I should actually be creating instances for every "object."
To me (and maybe I'm being naive here), a web app is all about making very short, stateless requests to alter or retrieve records in a database. The objects can't persist between requests. So it feels rather pointless to load data from the database, construct an object from that data, make a small update, save the data from the object back to the database, and then throw the object away. The loading/saving code seems to be a lot of work for nothing. [clarification: a waste of development time, not processing time... not too concerned about overhead]
The alternative is to have a bunch of singletons (or classes with static methods) that just provide a nice, organized abstraction layer to the database layer. I guess writing code in this manner just doesn't feel truly OO. Am I missing something or is that style fine?
Yes, you could summarise the benefits of OO as "code organization"; but this is true for all languages (not just PHP). In reality, it's more than that; it's about how you think about your data structures and algorithms, i.e. about how they map to concepts in the problem domain, how they relate to one another (ownership, parent-child, polymorphism, etc.), and how they expose clean, consistent interfaces to one another (encapsulation). If these concepts would benefit your application, and outweigh the extra development time vs. a quick-and-hacky procedural solution, then go for it.
I don't think persistence has anything to do with it.
I think you should question why you've been asked "to make sure it was OO". This seems like a pretty arbitrary request without further justification. Normally, the approach should be to write your application in the style that best suits the requirements, not arbitrary whims...
Singletons are essentially just global variables with some namespace sugar added in. There are a few main benefits to programming with objects and classes that you just don't get from straight procedural programming. One is inheritance, as you mentioned. Another is the namespacing - you can have a code to compress the lot into a single include file (more meaningful in interpreted languages like PHP than in compiled languages).
Objects are essentially a collection of functions with a shared state (though singletons make that a global state. Beware.) As you pointed out the benefit is mostly that that state is transparently shared by the functions without needing to explicitly pass it every single call. If you have various functions per request operating on shared data and wish them to be specialized forms of a general set of functions, OOP is probably a good fit.
Since you have been tasked to "make sure it is object oriented", I'd take some time to consider common groups of functions, generalizations of same, etc.
In the end the setup/teardown time of the objects isn't too bad - and it might even save some development time in the future if you do a good job.
I think OOP is just a programming style and has nothing to do with developing an application. What you need is a pattern that provides a sufficient abstraction layer (for example: MVC).
My recommendation is: Fat-Free.
It's tiny, simple and quickly take you to the minimal viable version of your product. It has everything that you might need (Caching, ORM, CRUD, Captcha...) and is so flexible that you can use any pattern and with your custom directories hierarchy.
Check out the extensive documentation. The only issue is that it requires PHP 5.3. I think it's reasonable considering the options and flexibility it offers. It really changes the way you work; you should definitively give it a shot.
Like most things in life answer is somewhere in a middle.
Todays application use ORMs (for example doctrine for php) for different kind of optimization, better understanding of database approach (which is important for larger dev teams), easier update of the code, abbstraction layer that is well known to people who join the project, caching mechanisms,....
Classes with static methods are just fine if you are doing some smaller project on your own, but when more people are involved in progress you simply need something more robust and standardized.
There are many debates on whether Object Oriented Programming is good or not. But, using OOP in Php is slower. Would it be a good trade to use procedural programming and faster speed and OOP with slower speed (since classes have to be initiated every time a page loads and big websites will start to become slow).
More importantly, would it be good to wrap stuff inside a class and use static functions or would it be better to just have many lying functions with a prefix ex: wp_function().
If the reason you're worried about using OO with PHP is speed, fear not: PHP is a slow language all around. If you're doing something that's processor-intensive enough for the speed loss from using objects to matter, you shouldn't be using PHP at all.
With regards to static functions, this is a design choice, but I'd err on the side of avoiding classes made up entirely of static functions. There's really no advantage to it over prefixes, and using a construct just because it's there isn't a good idea.
Yes, it is almost always a good idea to use OOP. This is because OOP is a style of coding, and coding styles for the most part are easily able to be transferred accross languages.
People don't use coding-styles because they use a certain language. People use coding styles because the style of coding offers good methods to do things they feel are desirable. Therefore, as long as the basic elements are there (inheritance, class properties, etc), it will always be viable to write in that coding style.
No, using procedural functions to access them probably isn't a good idea. This is because, you probably will have to do something like this to maintain the state.
function myFunc()
{
global $class;
$class->doMethod();
}
function myFunc2()
{
global $class;
$class->doMethod2();
}
This is a bad idea as it creates a ton of global state.
I strongly disagree with Chacha102's answer.
A proper answer to this question would fill several books - never mind a 20 line post here.
Both approaches have their benefits and drawbacks. I would recommend anyone who wants to consider themselves a good programmer to have significant experience in procedural, non-procedural and object-oriented programming. As well as experience with different methodologies such as SCRUM, cascade and RAD.
Regarding PHPs suitability for OO vs procedural coding, certainly the roots of the language are in the latter (but note that both Java and ASP are hybrid rather than true OO languages).
Peronally, I tend to write procedural code when I need to produce something which is either very simple or must have its behaviour to be thouroughly defined and predictable. However when writing complex code where the behaviour will vary greatly at run-time, I find OO to be vastly more efficient in terms of developer time - despite the design being based around a finite set of use-cases.
To argue that you should always write procedural code because it will run faster than OO code:
1) is not necessarily true
2) totally ignores the relative cost of developer time vs hardware costs
would it be good to wrap stuff inside a class and use static functions
Given that namespaces are now available in PHP, this is a really messy way to avoid namespace collisions and not something I would recommend.
C.
The same arguments about performance were made about Objective C and C++ back in the day. And the answer to that problem was to take advantage of available memory and processing power that is continuously getting bigger, better and faster.
Yes, OO requires more resources to run. But the benefits of using OO outweigh the hardware cost $$ (which is likely to be insignificant) of supporting OO applications.
It is, however, a good thing to be concerned about software performance. However looking under the hood of procedural vs. oo as a place to start is a bit misguided. You need to be focused on writing efficient code to begin with, whether procedural or OO (and both are relevant).
Keep in mind that even though PHP may not be the fastest platform out there (Java, for instance, kicks its butt) PHP is used to power some of the most traffic heavy websites on the Internet: namely Facebook.
If you have any other doubts about PHP and OO, just look at Zend and Magento (based on Zend). Magento is a VERY resource-intensive platform, memory usage can be upwards of 36MB per instance. However the platform itself is capable of handling millions of hits. This is because a properly configured server environment with a healthy serving of hardware resources make all the benefits of using OO far outshine the cost of the server itself. But in a world of clustered computers, NOT using the processing power and memory (responsibly) available to you is--IMHO--clinical insanity.
In my humble opinion, PHP developers should not try to go solely one direction. (procedural vs object-oriented) In some cases, all you need is a few global functions, other times it is more beneficial to use objects. Don't try to force everything one way or the other, be flexible and use what works best for each situation.
I was curious of this myself. Unfortunately after I changed my code from procedural to oop I ran some benchmarks and not beforehand.
Here's the benchmark code.
class game{
function maxp($val){
return max(0,pow($val,0.5));
}
}
$game = new game;
for($i=0;$i<100000;$i++){
$game->maxp(100);
//game::maxp(100);
}
OOP results ranged between 0.13 and 0.2 seconds;
Procedural results ranged between 0.08 and 0.1 seconds.
The results remained consistent over a good length of time.
I encourage you to run your own tests.
php 5.4.3
There's really no perfect answer since it depends on so many unknown variables, and then it doesn't have to be all-or-nothing.
For example, if you split your application into the MVC model, you might have your Model be OO but keep the Controller more simplistically procedural.
You could use classes as a means to simply group common static functions, or you could take it a lot farther into the active record pattern.
If you're building a small single-page webform that shoots a POST off in an email, you really don't need OO--lest you perhaps include an existing mail class to leverage.
Nobody can give you proper advice without understanding the project you're taking on.
That said, if your only concern is speed, then OO will be slightly slower. And there's a lot of sneaky things you can do in even procedural PHP to mimic some of the OO gains. But unless you're taking on a huge project, the added overhead will never amount to much. And by the time you have a huge project, the pros of OO might outweigh the cons of its overhead.
OOP has more merits than its de-merits. See PHP OOP, What Are The Benefits?. Also see for OOP vs PP in PHP.
Yes as your application grows.. (and it will) it will save you many hours of frustration. And repeating yourself (copying pasting code all over the place).. :)
I'm building a PHP site, but for now the only PHP I'm using is a half-dozen or so includes on certain pages. (I will probably use some database queries eventually.)
Are simple include() statements a concern for speed or scaling, as opposed to static HTML? What kinds of things tend to cause a site to bog down?
Certainly include() is slower than static pages. However, with modern systems you're not likely to see this as a bottleneck for a long time - if ever. The benefits of using includes to keep common parts of your site up to date outweigh the tiny performance hit, in my opinion (having different navigation on one page because you forgot to update it leads to a bad user experience, and thus bad feelings about your site/company/whatever).
Using caching will really not help either - caching code is going to be slower than just an include(). The only time caching will benefit you is if you're doing computationally-intensive calculations (very rare, on web pages), or grabbing data from a database.
Sounds like you are participating in a bit of premature optimization. If the application is not built, while performance concerns are good to be aware of, your primary concern should be getting the app written.
Includes are a fact of life. Don't worry about number, worry about keeping your code well organized (PEAR folder structure is a lovely thing, if you don't know what I'm talking about look at the structure of the Zend Framework class files).
Focus on getting the application written with a reasonable amount of abstraction. Group all of your DB calls into a class (or classes) so that you minimize code duplication (KISS principles and all) and when it comes time to refactor and optimize your queries they are centrally located. Also get started on some unit testing to prevent regression.
Once the application is up and running, don't ask us what is faster or better since it depends on each application what your bottleneck will be. It may turn out that even though you have lots of includes, your loops are eating up your time, or whatever. Use XDebug and profile your code once its up and running. Look for the segments of code that are eating up a disproportionate amount of time then refactor. If you focus too much now on the performance hit between include and include_once you'll end up chasing a ghost when those curl requests running in sync are eating your breakfast.
Though in the mean time, the best suggestions are look through the php.net manual and make sure if there's a built in function doing something you are trying to do, use it! PHP's C-based extensions will always be faster than any PHP code that you could write, and you'll be surprised how much of what you are trying to do is done already.
But again, I cannot stress this enough, premature optimization is BAD!!! Just get your application up off the ground with good levels of abstraction, profile it, then fix what actually is eating up your time rather than fixing what you think might eat up your time.
Strictly speaking, straight HTML will always serve faster than a server-side approach since the server doesn't have to do any interpretation of the code.
To answer the bigger question, there are a number of things that will cause your site to bog down; there's just no specific threshold for when your code is causing the problem vs. PHP. (keep in mind that many of Yahoo's sites are PHP-driven, so don't think that PHP can't scale).
One thing I've noticed is that the PHP-driven sites that are the slowest are the ones that include more than is necessary to display a specific page. OSCommerce (oscommerce.com) is one of the most popular PHP-driven shopping carts. It has a bad habit, however, of including all of their core functionality (just in case it's needed) on every single page. So even if you don't need to display an 'info box', the function is loaded.
On the other hand, there are many PHP frameworks out there (such as CakePHP, Symfony, and CodeIgniter) that take a 'load it as you need it' approach.
I would advise the following:
Don't include more functionality than you need for a specific page
Keep base functions separate (use an MVC approach when possible)
Use require_once instead of include if you think you'll have nested includes (e.g. page A includes file B which includes file C). This will avoid including the same file more than once. It will also stop the process if a file can't be found; thus helping your troubleshooting process ;)
Cache static pages as HTML if possible - to avoid having to reparse when things don't change
Nah includes are fine, nothing to worry about there.
You might want to think about tweaking your caching headers a bit at some point, but unless you're getting significant hits it should be no problem. Assuming this is all static data, you could even consider converting the whole site to static HTML (easiest way: write a script that grabs every page via the webserver and dumps it out in a matching dir structure)
Most web applications are limited by the speed of their database (or whatever their external storage is, but 9/10 times that'll be a database), the application code is rarely cause for concern, and it doesn't sound like you're doing anything you need to worry about yet.
Before you make any long-lasting decisions about how to structure the code for your site, I would recommend that you do some reading on the Model-View-Controller design pattern. While there are others this one appears to be gaining a great deal of ground in web development circles and certainly will be around for a while. You might want to take a look at some of the other design patterns suggested by Martin Fowler in his Patterns of Enterprise Application Architecture before making any final decisions about what sort of design will best fit your needs.
Depending on the size and scope of your project, you may want to go with a ready-made framework for PHP like Zend Framework or PHP On Trax or you may decide to build your own solution.
Specifically regarding the rendering of HTML content I would strongly recommend that you use some form of templating in order to keep your business logic separate from your display logic. I've found that this one simple rule in my development has saved me hours of work when one or the other needed to be changed. I've used http://www.smarty.net/">Smarty and I know that most of the frameworks out there either have a template system of their own or provide a plug-in architecture that allows you to use your own preferred method. As you look at possible solutions, I would recommend that you look for one that is capable of creating cached versions.
Lastly, if you're concerned about speed on the back-end then I would highly recommend that you look at ways to minimize your calls your back-end data store (whether it be a database or just system files). Try to avoid loading and rendering too much content (say a large report stored in a table that contains hundreds of records) all at once. If possible look for ways to make the user interface load smaller bits of data at a time.
And if you're specifically concerned about the actual load time of your html content and its CSS, Javascript or other dependencies I would recommend that you review these suggestions from the guys at Yahoo!.
To add on what JayTee mentioned - loading functionality when you need it. If you're not using any of the frameworks that do this automatically, you might want to look into the __autoload() functionality that was introduced in PHP5 - basically, your own logic can be invoked when you instantiate a particular class if it's not already loaded. This gives you a chance to include() a file that defines that class on-demand.
The biggest thing you can do to speed up your application is to use an Opcode cache, like APC. There's an excellent list and description available on Wikipedia.
As far as simple includes are concerned, be careful not to include too many files on each request as the disk I/O can cause your application not to scale well. A few dozen includes should be fine, but it's generally a good idea to package your most commonly included files into a single script so you only have one include. The cost in memory of having a few classes here and there you don't need loaded will be better than the cost of disk I/O for including hundreds of smaller files.