Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65846 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 14092 invoked from network); 14 Feb 2013 19:08:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Feb 2013 19:08:12 -0000 Authentication-Results: pb1.pair.com smtp.mail=brianofish@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=php@bof.de; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.53 as permitted sender) X-PHP-List-Original-Sender: brianofish@gmail.com X-Host-Fingerprint: 74.125.83.53 mail-ee0-f53.google.com Received: from [74.125.83.53] ([74.125.83.53:44846] helo=mail-ee0-f53.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A6/5B-58622-B163D115 for ; Thu, 14 Feb 2013 14:08:11 -0500 Received: by mail-ee0-f53.google.com with SMTP id e53so1411748eek.26 for ; Thu, 14 Feb 2013 11:08:08 -0800 (PST) X-Received: by 10.14.182.137 with SMTP id o9mr55857226eem.13.1360868888703; Thu, 14 Feb 2013 11:08:08 -0800 (PST) Received: from rofl.localnet ([213.135.15.139]) by mx.google.com with ESMTPS id o3sm80051181eem.15.2013.02.14.11.08.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 11:08:07 -0800 (PST) To: internals@lists.php.net Cc: Stas Malyshev , Alexey Zakhlestin , Zeev Suraski , Christopher Jones Date: Thu, 14 Feb 2013 20:08:04 +0100 Message-ID: <7520555.O0k0m4D5oi@rofl> User-Agent: KMail/4.10 (Linux/3.7.7-k10-bof; KDE/4.10.0; x86_64; ; ) In-Reply-To: <511D2BD6.2090903@sugarcrm.com> References: <511D2BD6.2090903@sugarcrm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [PHP-DEV] Zend Optimizer+ Source Code now available From: php@bof.de (Patrick Schaaf) On Thursday 14 February 2013 10:24:22 Stas Malyshev wrote: > > For most scripts, optimizations are not really worth it unless you run > the same code over and over, so for CLI it would be noticeable only if > you run long-running CPU-intensive server. Apart from the long-running servers, there is also cronjobs. I have quite a number of them running on some of my servers, some of them once per minute, and they all share a certain number of classes between them. I imagine their startup and execution could profit a bit from an opcode cache. What keeps an opcode cache from using a persistent memory mapped file, maybe one per UID for security reasons, to cache opcodes from separate CLI invocations? best regards Patrick