On Wed, 06 Jan 2010 23:20:26 -0500, kolb0...@umn.edu (Daniel Kolbo) wrote:

>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
>> "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

Reply via email to