On Wed, 06 Jan 2010 23:20:26 -0500, kolb0057@xxxxxxx (Daniel Kolbo) wrote: >Daevid Vincent wrote: >> >> >>> -----Original Message----- >>> From: Al [mailto:news@xxxxxxxxxxxxx] >>> Sent: Wednesday, January 06, 2010 5:09 PM >>> To: php-general@xxxxxxxxxxxxx >>> Subject: Re: PHP programming strategy; lots of little >>> include files, or a few big ones? >>> >>> >>> >>> On 1/6/2010 7:18 PM, clancy_1@xxxxxxxxxxxx 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 >> >> "Some people, when confronted with a problem, think 'I know, I'll use >> XML.'" >> Now they have two problems. >> >> > >I had a similar issue but with classes (not functions). >I opted to keep my classes short and succinct, rather than shoving all >the method functionality into one all-purpose class. >Instead of blindly loading all the little classes on each http request, >I used (and was recommended on this list to use) __autoload(). The >script would only load my classes if the individual request needed it. >This helped to avoid the memory bloat. I've heard magic functions like >__autoload are a bit slower, but the code is so much cleaner b/c of it. > >Also, an opcode cache as suggested previously would facilitate the rapid >include of many small files. > >Unfortunately, php does not offer an __autoload() type function to >autoload functions. > >If you are able to encapsulate your functions functionality into classes >you may be able to use the above solution of using an opcode cache to >help __autoload() a bunch of small classes. Although PHP doesn't offer an _autoload() function to autoload functions, it does provide function_exists, and this can readily be used to achieve the same end: If (!function_exists(feedback_handler)) { include ('Feedback_handler.php'); } -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
