Re: [PEPr] +1 for Encryption::Crypt_HMAC2

From: Date: Thu, 05 Jul 2007 21:26:09 +0000
Subject: Re: [PEPr] +1 for Encryption::Crypt_HMAC2
Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-47235@lists.php.net to get a copy of this message
I'll try and dig up a reference. We had the exact same debate some months back on the Zend Framework mailing list and after a lot of confusion it was determined that opcode caches will cache the entire file (conditional or not) to memory. The only thing it can't cache are the function/class So the result is the file is cached (no filesystem read on next request) but functions and classes will still need to be built for every request from the cached file. Since filesystem ops are particularly costly the majority benefit is preserved - no slow file read. Given I only ever lazy load rarely required Exception classes, I doubt there's a real performance cost here - cutting out the Exception load is itself far more beneficial given how expensive require_once is (at least before PHP 5.2) and how that translates across a code base needing a bus load of Exception classes. Yes, the justification is purely for a platform without an opcode cache where lazy loading is a god send against Exception loading - but the cost to a system with an opcode cache is minimal. So unless the Zenders are all out crazy folk, the performance cost is just not worth measuring. I have tried too - trying to squeek it out of KCacheGrind is all but impossible even in simple code without the performance hit of a database connection. It's so tiny for Exceptions it's buried in that part of the performance dead zone not worth my time optimising. With the opcode cache disabled, the grind file's output is pretty striking - eliminating upfront Exception loads has a measurable impact especially on PHP 5.1.x where require_once constructs are horrendously slow. Anyway, if you really want a performance jump you should check out Crypt_DiffieHellman using BCMath. That will make you cry :). Regards, Paddy Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com ----- Original Message ---- From: till <till@php.net> To: Paul M Jones <pmjones@ciaweb.net> Cc: PEAR developer mailinglist <pear-dev@lists.php.net>; Pádraic Brady <padraic.brady@yahoo.com> Sent: Thursday, July 5, 2007 6:00:34 PM Subject: Re: [PEAR-DEV] [PEPr] +1 for Encryption::Crypt_HMAC2 On 7/5/07, Paul M Jones <pmjones@ciaweb.net> wrote: > On Jul 4, 2007, at 11:16 AM, Till Klampaeckel wrote: > > > Till Klampaeckel (http://pear.php.net/user/till) has voted +1 on > > the proposal for Encryption::Crypt_HMAC2. > > > > Proposal information: > > http://pear.php.net/pepr/pepr-proposal-show.php?id=495 > > Vote information: > > > > http://pear.php.net/pepr/pepr-vote-show.php?id=495&handle=till > > > > This vote is conditional. The condition is: > > > > * lazy loading breaks bytecode caching > > Is that so? I know that conditional class *definition* causes > bytecode-cache misses, but I was not aware that conditional include/ > require would cause trouble. Can you link to a reference on this? From what I understand, it attemps to cache the file, but since the include is inside a condition and runtime dependent, it would break the cache when the condition is evaluated. Or maybe even every time (disclaimer: not sure). Since lazyloading (autoload, conditional includes, etc.) in general is runtime dependent - that defeats the entire caching. I know it's convenient. ;-) Correct me if I am wrong. Till -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php ____________________________________________________________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/

« previous php.pear.dev (#47235) next »