On Wed, 6 Jan 2010 19:11:07 -0800, dae...@daevid.com ("Daevid Vincent") wrote:> > >> -----Original Message----- >> From: Al [mailto:n...@ridersite.org] >> Sent: Wednesday, January 06, 2010 5:09 PM >> To: php-general@lists.php.net >> Subject: [PHP] Re: PHP programming strategy; lots of little >> include files, or a few big ones? >> >> >> >> On 1/6/2010 7:18 PM, 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? > >I think it's a case by case basis. Generally File I/O is expensive, but >then again, as you say, having everything in a couple files is also >sub-optimal for organizing and keeping things modular. > >I suggest you go with smaller files that are organized into logical >'chunks'. For example, functions that are used frequently are grouped into >a common.inc.php rather than by topic (such as file/date/xml/forms/etc). >And then use topical includes for the rest. > >More importantly, I suggest you get a good caching system like memecached >or any of the others out there. Then you can pre-compile and load these >files and the whole point becomes close to moot. > >ÐÆ5ÏÐ >http://daevid.com Thank you all for your comments. I did not know about bytecode caches. They're an interesting concept, but if I am interpreting the paper http://itst.net/654-php-on-fire-three-opcode-caches-compared correctly they only double the average speed of operation, which is rather less than I would have anticipated. As I would have to understand yet another system to implement them, and I suspect I'd have to do a significant amount of rearranging, I don't think I will worry about them unless my webpages unexpectedly become extremely popular. Al's suggestion that my code is probably infinitesimal compared with PHP suggests that I shouldn't be worrying about memory requirements. On the other hand I agree with David that the advantages of using relatively small easy to understand modules probably outweigh the costs of loading a larger number of files. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
