[development] Strip out theme functions into a .theme file

[Chris Johnson]

Doing good benchmarks is the right way to determine the impact of this kind of 
change.  And as Bèr says, the kind and use of the system upon which the 
benchmark runs is important.  Although I am 95% sure fopen() does not do any 
kind of locking, his point is still valid.

Note also that any decent filesystem is going to be caching file handles 
(directories and inodes on most *nix filesystems), so repeated openings of the 
same files is way fast compared to the first open off disk.  Such a variable 
is yet another reason to benchmark and to describe well the host situation 
under which the benchmark was run.

I'm glad to see so much activity on improving Drupal's performance!

Adrian Rossouw wrote:
> well. additionally the code from the templates might even be cached to 
> the db (we actually had this implemented already)
> 
> an opcode cache would make this unneeded though.
> 
> On 8/4/06, *Bèr Kessels* <ber at webschuur.com <mailto:ber at webschuur.com>> 
> wrote:
> 
>     Op vrijdag 4 augustus 2006 12:23, schreef Dries Buytaert:
>      > We did some preliminary benchmarks and noticed a 10% performance
>      > cost. This cost was not caused by fopen() but by the way variables
>      > were handled. This might be less of an issue with this patch.
>      >
>      > It's well worth exploring this further, IMO, but rather than
>     guessing
>      > we should collect factual data.
> 
> 
>     Something that is *very* important when benching fopens-freads is the
>     underlying file system and the activity of the HD.
> 
>     I was told that a fopen - fread (php include() ) often does a file
>     lock too.