On Wed, 6 Jan 2010 19:11:07 -0800, daevid@xxxxxxxxxx ("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
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
