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@webschuur.com <mailto:ber@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.