1. Efficiency question.
Out of curiosity... What's more efficient, having a lot of small include files
(each with only a couple routines/variables) or a few large ones (with everything
in one file) or is there no difference?
2. Re: Efficiency question.
D. Newhall wrote:
>
> Out of curiosity... What's more efficient, having a lot of small include files
> (each
> with only a couple routines/variables) or a few large ones (with everything in
> one
> file) or is there no difference?
>
Having alot of small ones if more efficent. It takes more time with v2.5 to scan
and parse included files.. Becides you should have a include for each catagory,
because more organized that way.
Regards,
Vincent
----------------------------------------------
___ __________ ___
/__/\ /__________\ |\ _\
\::\'\ //::::::::::\\ |'|::|
\::\'\ //:::_::::_:::\\ |'|::|
\::\'\ //::/ |::| \::\\ |'|::|
\::\'\ //::/ |::| \::\\|'|::|
\::\'\__//::/ |::| \::\|'|::|
\::\','/::/ |::| \::\\|::|
\::\_/::/ |::| \::\|::|
\::,::/ |::| \:::::|
\___/ |__| \____|
.``.
',,'
3. Re: Efficiency question.
D. Newhall wrote:
>
> Out of curiosity... What's more efficient, having a lot of small include files
> (each
> with only a couple routines/variables) or a few large ones (with everything in
> one
> file) or is there no difference?
With respect to run-time effeciency there is no real difference. The longer
parsing time for large files is traded off for the overheads in opening and
closing many small files. And at that, the parse time is still measured in
milli-seconds per execution so does it really matter?
However, with respect to coding effeciency: smaller files would be preferred. It
is more cost-effective to maintain smaller files, and they enhance discrete
modularization. Coders using the library can then mix&match according to their
needs.
Use a good naming convention to get around the poor namespace implementation.
And create a useful cross-index for the documentation.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
