> -----Original Message----- > From: Clint Priest [mailto:cpri...@zerocue.com] > Sent: Tuesday, January 29, 2013 3:30 PM > To: Anthony Ferrara > Cc: Tyler Sommer; Zeev Suraski; internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP > distribution > > On 1/29/2013 5:23 AM, Anthony Ferrara wrote: > > Additionally, I don't like the precedent that this sets for future > > releases. That it's ok to break the timebox for some feature. In this > > case I think we can justify it, but future cases may use this to > > justify waiting when it's not completely justified in itself. I'm not > > sure how we can rectify this concern, but I figured it was worth mentioning. > I would agree with this sentiment, time boxing from my own personal > experience just completely breaks down if you let anything get in the way of it, if > you let that box slip for any reason, other reasons become easily justifyable. If > 5.5 is due for release, we should not delay it for 2 months to get an opcode > cache into core. > > Additionally: > > 1) I believe Optimizer+ is the opcode cache that's been discussed but it's not > thread safe?
It's presently not thread safe. Just to be sure we're all on the same page, this is only meaningful if you're running PHP on Windows and not using FastCGI; It's completely meaningless in any other scenario (i.e. for the vast majority of users); That said, adding thread safety support for Optimizer+ is a fairly easy task. We've never done it because none of our commercial products use thread-safe PHP. I'll update the RFC to clarify the scope of this limitation. > 2) Isn't APC the standard? Is it in such bad shape it is not even being considered > any longer? Did you read the RFC? Yes, it is considered, and it's certainly an option on the table, with advantages and disadvantages. There's a whole section in the RFC about it. > 3) There has never been a bundled opcode cache that I'm aware of, one more > release without one is not going to surprise many people > > 4) Waiting for a 5.6 release will give everyone an entire year to get this into core > and well tested which based on all the hoopla about how critical APC/opcode > caches are to the core it makes sense that integration is going to be a long and > painful process. I for one am not very fond of having a release every 12 months, and the current pace of every 18 month seems rapid enough. So we'd be talking about a year and a half, not a year. My opinion is that looking at our adoption patterns, delaying by 2 months and providing an opcode cache right off the bat would be much preferable to the vast majority of users. People are barely using 5.4 today - it would hardly make a difference if we release 5.5 two months earlier or two months later. But that too would be up for discussion and voting. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
