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.

Thank you all for your comments. I did not know about bytecode caches. They're 
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 

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

Reply via email to