[PHP] PHP programming strategy; lots of little include files, or a few big ones?
I have a flexible program, which can do many different things according to the type of data it is fed. Ideally the flexibility is achieved by calling different functions, though when the functionality is ill-defined I sometimes just include blocks of code. Ideally, from the point of program maintenance, each module should not be too long -- preferably just a page or so. This doesn't raise problems in a compiled language, but in an interpreted language like PHP the programmer must decide whether to lump a whole lot of functions into a single large include file, or to include lots of little files as the particular functions are needed. The first case can lead to memory bloat, as there are likely to be a lot of unused functions in memory on any given pass, whereas the second case may require lots of little files to be loaded. Are there likely to be significant performance costs for either approach, and what are your feelings about the relative virtues of the two approaches? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP programming strategy; lots of little include files, or a few big ones?
clanc...@cybec.com.au wrote: I have a flexible program, which can do many different things according to the type of data it is fed. Ideally the flexibility is achieved by calling different functions, though when the functionality is ill-defined I sometimes just include blocks of code. Ideally, from the point of program maintenance, each module should not be too long -- preferably just a page or so. This doesn't raise problems in a compiled language, but in an interpreted language like PHP the programmer must decide whether to lump a whole lot of functions into a single large include file, or to include lots of little files as the particular functions are needed. The first case can lead to memory bloat, as there are likely to be a lot of unused functions in memory on any given pass, whereas the second case may require lots of little files to be loaded. Are there likely to be significant performance costs for either approach, and what are your feelings about the relative virtues of the two approaches? Use a bytecode cache and stop worrying. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP programming strategy
On Saturday 01 August 2009 11:01:11 pm Eddie Drapkin wrote: I actually benchmarked that once. I had a reasonably large PHP file that was, in fact, over 50% docblocks. That's not even counting inline comments. While trying to find things to optimize, removing about 800 lines worth of comments (all of the docblocks) did, in fact, produce a noticeable performance difference. It was only barely noticeable, but it just barely registered as more than random sampling jitter. I actually concluded that if cutting the file *in half* was only just barely noticeable, then it really wasn't worth the effort. Yeah but what happens if you run the script through the tokenizer and strip ALL comments, unnecessary whitespace, newline characters, etc. out? Honestly? I think you'll save more CPU time by eliminating one SQL query. Most files are not 60% comments. In a file that is only about 20% comments, I doubt you could even measure the difference. There are far far far more useful ways to optimize your code. (Note that this is different for CSS or Javascript, where compressors like that are commonplace because you have to transfer the entire file over the network repeatedly, which is a few orders of magnitude slower than system memory. Compressors and aggregators there make sense. PHP code never leaves the server, so those benefits don't exist.) -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP programming strategy
On Sun, Aug 2, 2009 at 2:24 PM, Larry Garfieldla...@garfieldtech.com wrote: On Saturday 01 August 2009 11:01:11 pm Eddie Drapkin wrote: I actually benchmarked that once. I had a reasonably large PHP file that was, in fact, over 50% docblocks. That's not even counting inline comments. While trying to find things to optimize, removing about 800 lines worth of comments (all of the docblocks) did, in fact, produce a noticeable performance difference. It was only barely noticeable, but it just barely registered as more than random sampling jitter. I actually concluded that if cutting the file *in half* was only just barely noticeable, then it really wasn't worth the effort. Yeah but what happens if you run the script through the tokenizer and strip ALL comments, unnecessary whitespace, newline characters, etc. out? Honestly? I think you'll save more CPU time by eliminating one SQL query. Most files are not 60% comments. In a file that is only about 20% comments, I doubt you could even measure the difference. There are far far far more useful ways to optimize your code. (Note that this is different for CSS or Javascript, where compressors like that are commonplace because you have to transfer the entire file over the network repeatedly, which is a few orders of magnitude slower than system memory. Compressors and aggregators there make sense. PHP code never leaves the server, so those benefits don't exist.) -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Seems the sarcasm / attempted comedy was lost in translation! --Eddie -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP programming strategy
Is anyone here interested in discussing programming strategy, or or know of a discussion group which is interested in the subject? The sorts of questions I am interested in are: 1. I have a highly variable program which always shows the same page, but which includes different modules to give different results. The various modules call on different functions. Is it better to minimise memory by including only the functions actually required, but increase the number of files included, or to bundle all the functions into one file, thereby reducing the number of files included but increasing the size in memory? 2. As PHP is an interpreted program comments certainly increase the memory requirements, and presumably they slow down the operation of the program. Would stripping out the comments before uploading the production version give any visible improvement in performance? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP programming strategy
On Saturday 01 August 2009 8:25:40 pm Clancy wrote: Is anyone here interested in discussing programming strategy, or or know of a discussion group which is interested in the subject? The sorts of questions I am interested in are: 1. I have a highly variable program which always shows the same page, but which includes different modules to give different results. The various modules call on different functions. Is it better to minimise memory by including only the functions actually required, but increase the number of files included, or to bundle all the functions into one file, thereby reducing the number of files included but increasing the size in memory? That depends greatly on your usage patterns. Does your application make lots of sideways calls to integrate different modules, or is just switch on a GET parameter, run this function, done? If the latter, then lazy-loading just the one or two files you want is probably better. If the former, you'd need a lot of interesting logic to make lazy-loading work well enough to be justified. (I've been working on such a system for Drupal for the past year, and it's not easy to get right because there can be a fair bit of overhead.) If your application is heavily OOP then PHP supports dynamic autoloading of classes, which can greatly simplify your code logic but at the same time the autoload mechanism itself is not free either. The age of the computer matters, too. Modern hard drives are faster than they used to be, and more recent OS versions can do some fairly aggressive caching if the files you're reading all fit inside the OS cache somewhere in memory so you may not actually hit disk to load each of your files. 2. As PHP is an interpreted program comments certainly increase the memory requirements, and presumably they slow down the operation of the program. Would stripping out the comments before uploading the production version give any visible improvement in performance? I actually benchmarked that once. I had a reasonably large PHP file that was, in fact, over 50% docblocks. That's not even counting inline comments. While trying to find things to optimize, removing about 800 lines worth of comments (all of the docblocks) did, in fact, produce a noticeable performance difference. It was only barely noticeable, but it just barely registered as more than random sampling jitter. I actually concluded that if cutting the file *in half* was only just barely noticeable, then it really wasn't worth the effort. Just install an opcode cache. That will take care of most of your memory issues. :-) -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP programming strategy
I actually benchmarked that once. I had a reasonably large PHP file that was, in fact, over 50% docblocks. That's not even counting inline comments. While trying to find things to optimize, removing about 800 lines worth of comments (all of the docblocks) did, in fact, produce a noticeable performance difference. It was only barely noticeable, but it just barely registered as more than random sampling jitter. I actually concluded that if cutting the file *in half* was only just barely noticeable, then it really wasn't worth the effort. Yeah but what happens if you run the script through the tokenizer and strip ALL comments, unnecessary whitespace, newline characters, etc. out? Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP programming strategy
On Sun, Aug 02, 2009 at 11:25:40AM +1000, Clancy wrote: Is anyone here interested in discussing programming strategy, or or know of a discussion group which is interested in the subject? The sorts of questions I am interested in are: 1. I have a highly variable program which always shows the same page, but which includes different modules to give different results. The various modules call on different functions. Is it better to minimise memory by including only the functions actually required, but increase the number of files included, or to bundle all the functions into one file, thereby reducing the number of files included but increasing the size in memory? My advice would be to only load the modules you need, no matter how convoluted the logic you must use to do that. A lot of PHP programmers are very sloppy about memory usage, falling back on the cache argument, etc. But there's no reason to use more memory than you have to. However, there is an issue if all these modules are scattered about everywhere. You also have to look at the overhead on the server when it's having to open 15 files for every page displayed. That's silly as well. So it's a trade-off. If you have the latter problem, I'd probably opt to put everything in one or a few files. In my opinion, disk thrashing on a busy internet server is worse than gobbling up more memory. That disk thrashing is likely to have a negative effect on all the other users of that server. 2. As PHP is an interpreted program comments certainly increase the memory requirements, and presumably they slow down the operation of the program. Would stripping out the comments before uploading the production version give any visible improvement in performance? I bow to those who have profiled this, as far as performance goes. However, remember, you have to *maintain* this code. In a trade-off between performance and maintainability, I'd opt for maintainability. You'll thank yourself in the future. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
