Re: [PEPr] +1 for Encryption::Crypt_HMAC2
| From: | Pádraic Brady | 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/