RE: [PHP-WIN] speed of require/include

> -----Original Message----- > From: Keith Davis [mailto:keithdavis@pridedallas.com] > Sent: Wednesday, October 20, 2010 2:09 PM > To: Tac Tacelosky; Tommy Pham > Cc: php-windows > Subject: RE: [PHP-WIN] speed of require/include > > Or use Wincache. That's what we are using. Runs like a champ. > > Keith Davis (214) 906-5183 > > > -----Original Message----- > From: Tac Tacelosky [mailto:tacman@gmail.com] > Sent: Wednesday, October 20, 2010 4:05 PM > To: Tommy Pham > Cc: php-windows > Subject: Re: [PHP-WIN] speed of require/include > > If you have the RAM, install php_apc -- once the scripts are included once, > the tokenized php will be cached in memory, can be a significant > performance boost. > > We also use it for "global" variables that don't change across scripts, such as > state and country names. Great tool, I wish it were built into PHP instead of > a pecl module. > > Tac > > On Wed, Oct 20, 2010 at 4:50 PM, Tommy Pham <tommyhp2@gmail.com> > wrote: > > > Hi everyone, > > > > I think this question is general PHP but because I'm using Windows for > > > development at the moment and was wondering if it's related to > Windows. > > Does the speed of require/require_once/include/include_once depends > on > > > disk activity, buffers (disks, controller, Windows)? I can't seem to > > get steady time from xdebug profile... it varies from 27ms to 170ms > > on one of my scripts while another script in the same framework with > > less require/include always have a steady ~6.5ms (the previous has 30 > > requires/includes and the latter has 8 requires/includes). I only > > have the skeleton of the framework for my project (no DB access, no > > fancy html/xml output). I'm running PHP > > 5.3.3 FastCGI on Windows 2008 R2 x64 w/ 4GB RAM. SATA RAID controller > > > is 3ware 9650se. > > > > Thanks for your time, > > Tommy > > > > > Hi, Thanks for your advices. I'll look into both later but for the moment I don't want to implement any caching yet as it will lead me to develop sloppy code because I see fast performance. Thanks, Tommy