This question was asked here before, but none of the answers really tried to answer the actual question asked, so I'm asking it in a different way. Is loading a single class of 20,000 lines with 100s of functions more resource intensive in any way than breaking up the code to smaller classes with fewer functions each and loading these smaller classes as needed?
The larger a script or class is, the more memory this uses per instance. Out of the box, PHP doesn't have a way to share the memory space of libraries and classes, so creating massive scripts for a website is not a great idea.
The typical approach should be to break classes down into blocks such that you need only include per script what you actually need to run that script.
Also, it's unlikely to cause you performance problems unless you've got a huge amount of traffic - and then you could probably fix your problems easier than refactoring classes.
When a script is loaded, it requires a fixed amount of memory to parse it. The larger it is, the more memory it requires. Next, the script itself is executed, running any top-level code (not in a
class or global function). If that includes any require/include statements, those scripts are loaded (if necessary). If it creates objects, that takes more memory.
However, the size of each instance of the class is affected only by the data it stores. This correction aside, the advice here is spot on: split your classes based on responsibilities. The reason for this has also to do with ease of development than performance. Say you have one monster class filled with static methods. If your application uses most of those methods for each request, splitting it will have no performance benefit because both scripts will end up being loaded anyway. But if you can group the methods into logical subsystems, they will be easier to understand and work with.
One big class require single cycle to compile into binary code (op-code).
Many smaller classes using lesser memory but require more compilation, and the memory use for compilation will be accumulated.
Is really depend how many classes/files has been included in run-time.
So, solution for this, break into multiple classes and use APC or equivalent.
PS: the memory consumption for the big file is much smaller, because PHP do not need to re-compile the source into op-code (if you reluctant to break the big class into smaller)
Related
I have an existing php website, that is written in an old fashion way.
Every page has the same pattern
<?php
require_once("config.php");
//Some code
require_once("header.php");
?>
Some HTML and PHP code mixture
<?php
require_once("footer.php");
?>
Where all the db connection, session data, language files are initiated at the "config.php" file.
And every DB access is done with a mysql_query call,
No OOP what-so-ever, purely procedural programming.
How would you to optimize this code structure in order to improve performance and make this website robust enough to handle heavy traffic ?
How would you to optimize this code structure in order to improve performance and make this website robust enough to handle heavy traffic ?
The structure you've shown us has very little scope for for optimization. Making it object-oriented will make it slower than it currently is. Note that the code within the included files may benefit greatly from various changes.
There's only 3 lines of code here. So not a lot of scope for tuning. The _once constructs add a (tiny) overhead, as does use of require rather than include - but this is a very small amount compared to what's likely to be happening in the code you've not shown us.
Where all the db connection, session data, language files are initiated at the "config.php" file
There are again marginal savings by delaying access to external resources until they are needed (and surrendering access immediately when they are no longer required) - but this is not an OO vs procedural issue.
Why will OO be slower?
Here the routing of requests is implemented via the the webserver - webservers are really good at this and usually very, very efficient. The alternative approach of using a front controller gives some scope for applying templating in a more manageable way and for applying late patching of the content (although it's arguable if this is a good idea). But using a front-controller pattern is not a requirement for OO.
Potentially, when written as OO code, redundant memory allocations hang around for longer - hence the runtime tends to have a larger memory footprint.
Overriding and decorating adds additional abstraction and processing overhead to the invocation of data transformations.
every DB access is done with a mysql_query call
There's several parts to this point. Yes, the mysql_ extension is deprecated and you should be looking to migrate this as a priority (sorry, but I can't recommend any good forward/backward shims) however it is mostly faster than the mysqlnd engine - the latter has a definite performance advantage with large datasets / high volume due to reduced memory load.
You seem to be convinced that there's something inherently wrong with procedural programming with regard to performance and scale. Nothing could be further from the truth. G-Wan, Apache httpd, Varnish, ATS, the Linux kernel are all written in C - not C++.
If you want to improve performance and scalability, then you're currently looking in the wrong place. And the only way to make significant in-roads is to to profile your code under relevant load levels.
If you really don't want to change your structure (OOP and mysql_*..., and even with these in fact), you should implement a cache system, to avoid the generation of content everytime. If you have some data that doesn't change often (like blog post, news or member profile), you can create a cache of 5 minutes on it, to lighten the SQL use. Google might help you for this.
There's also a lot of web techniques to optimize pages loading: use a CDN to load your static ressources, Varnish cache...
With PHP itself, there's also some methods, but a lot of blog post exists about that, just look here for example :) For example:
Avoid regex if possible
Initialize variable if you need it: it's 10 times slower to increment/decrement an non-initialized variable (which is ugly btw)
Don't call functions in for declaration, make temp variable instead
etc.
Don't hesitate to benchmark, make some tests with JMeter to simulate a pool of connections and see which page is slow and what you should optimize first.
Can a PHP application have too many functions? Does the execution of a large number of PHP functions hog memory and resources? My WordPress theme in-development has a lot of functions (probably more than 100 by the time I'm done) and I'm concerned that I might have too many.
Even if many functions led to more memory consumption, I'd advise you to use them anyway. A clear structure is much more important than performance.
Performance can be improved by throwing hardware at it, a badly structure application gets quickly very hard to maintain.
By the way: 100 functions are nothing!
100 functions is nothing to worry about. If your code is slow you should profile it to explicitly find the slow parts.
Remember, premature optimizations are evil
No, it can't. Actually, it is good to have many functions, because that means that you've divided your code into more manageable pieces. A good rule is to keep your functions small, have them do just one thing. Oh, and remember to name your functions so that the function name describes well what the function does.
Having a lots of methods will produce a small overhead in the execution time, but it is so insignificant compared with the benefits you get from having structured code, so I wouldn't worry about it.
I wouldn't be concerned about 100 functions. That's very few functions.
Global functions and methods are compiled, stored in memory, and indexed in a hash table (save for cached lookups implemented recently). You won't have performance deterioration when calling the functions as the number of functions grows, since accessing the hash table is done, on average, in constant time.
However, there will be more overhead parsing the scripts and, if you actually call all those functions, compiling them. This is not really a problem if the you use an opcode cache. There will also be more memory overhead, but typically, memory is not a problem in enterprise grade web servers, where it's more appropriate to try to serve the requests as fast as possible, without caring that much about the memory.
There are also stylistic issues. If you have too many global functions, consider whether:
You are duplicating code between those functions. Consider refactoring, moving the common code to other function and generalizing the behavior of the functions by adding parameters, where appropriate.
You would be better grouping functions that operate on the same data in an class.
In the end, worry about this only if you profile your application and find function calls to be a CPU bottleneck and function definitions to be a memory bottleneck.
Just make your code to do it's job. Don't care about your function count.
PHP has over 3000 functions in its core, so don't worry about adding too much.
I think yes a project can have too many functions. I don't know how you have setup your project but it sounds like you have function libraries. You may want to consider Object Oriented Development in the future. This allows you to encapsulate functionality into Objects. Therefore the object contains the functions and they are not visible to other objects (unless you want them to be). This helps to keep the API pollution down a lot.
For you memory concerns - I used to worry about this too, DON'T. Good programming practices are more important that speed. You will not even notice the difference on a Web Server anyway. Always favor maintainability over speed!
I currently have a AJAX heavy(almost everything) intranet webapp for a business. It is highly modularized(components and modules ala Joomla), with plenty of folders and files. ~ 80-100 different viewing pages (each very unique in it's own sense) on last count and will likely to increase in the near future.
I based around the design around commands and screens, the client request a command and sends the required data and receives the data that is displayed via javascript on the screen.
That said, there are generally two types of files, a display files with html, javascript, and a little php for templating. And also a php backend file with a single switch statement with actions such as, save, update and delete and maybe other function. Several pages/screens may use the same php backend.
Recently, I have been adding an server sided undo function that requires me to reuse some code. So, I took the chance to try out OOP but I notice that some functions are so simple, that creating a class, retrieving all the data then update all the related rows on the database seems like overkill for a simple action as speed is quite critical. Also I noticed there is only one class in an entire file.
So, what if the entire php is a class. So, between creating a class and methods, and using global variables and functions. Which is faster?
Writing object oriented PHP will not affect your performance at all. If you use extensions like Zend Optimizer, it can even work faster.
So, there's really no reason not to use the much cleaner and more easily maintainable object oriented paradigm in PHP.
Writing purely procedural code may even lead to a performance drop since optimizations can be much harder and small details that eat up execution time are more likely to occur in such a messy environment.
The question is misguided. The problem is not one of speed, it's one of code organization. Using only global functions and variables, and lots of them, it'll get harder and harder to avoid naming conflicts and keep everything organized. Classes help you package and abstract things. Execution speed is a secondary concern, and in most cases won't increase noticeably, if at all. Development speed though can increase significantly over time, since you'll have to deal less with conflicts.
Is there any gain to combining all of the classes for a project into one massive 'compressed' file (spaces and comments removed) vs loading each class as they are required (other than all of the classes are there so you don't have to require/include them, isn't that what we have __autoload for?)?
It seems to me that loading each class as needed would be a lot less strenuous on php.
Generally, in the vast majority of cases, for any non-trivial number of classes, you want some kind of dependency injection. The overhead of the dependency injection (via whatever method) will be dwarfed by the resources needed to parse a bunch of classes that won't get used in a particular request.
A lot has been written on the subject of how to efficiently manage loading classes as needed.
If you use a bytecode cache like APC, there's likely no performance gain to be had from "minifying" your PHP (removing whitespace and comments). The only benefit would be obfuscation -- which isn't going to buy you much anyway.
And yes -- loading 30 classes when you only need 1 is going to be a waste of resources.
I have main php-file with main class.
Also in this class i do
require_once("func.php");
which has many useful functions for my site.
Size of func.php is very big, because there is many functions for different actions on different pages. But I include it on every page, because including called by main class.
What I need to do for optimizing it?
Rewrite func.php to OOP and use in main class something like "$funcs->my_func()"? Will I won some performance? Functions which wasnt called would not occupy memory and CPU time?
Or I must rewrite func.php to many files and call each on specified page?
For example: for "about.php" I will include "about_func.php" with needed functions. But it isnt comfortable I think...
Please, help me :)
And sorry for my eng :)
How big is func.php? Are you sure the size is a problem.
This seems like a performance/optimization question at heart. Are you sure that optimization is warranted? Have you measured your page's performance and proved that including this big function file is to blame for its slowness?
I suggest you answer 1 & 2 to yourself before continuing. If the motivation for your question is cleaner design and modularization, then yes, I would agree that splitting a bug "utils" file into smaller files that share a responsibility or a general area of relevance is a good idea. If, on the other hand, this is a case of premature optimization, then you'd be better off leaving poor "func.php" along (hey, sometimes it's ok to have a big common utils file, as long as it's not hurting you).
Split it into oop classes and use the __autoload function of PHP5: http://www.php.net/manual/en/language.oop5.autoload.php
This wil load the classes only when needed and you don't have to worry about including all neccessary files. It won't give you any performance benefit but it's easier to manage smaller files for one purpose than a big one with several functions which are not dependent on each other.
Do you have a PHP accelerator enabled?
Zend Optimizer
eAccelerator
APC
Because they keep a "compiled" version of func.php in memory which should speed things up, without any code modifications.
Although I recommend OOP, it's not because of performance reasons.