Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:53435 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48655 invoked from network); 20 Jun 2011 17:17:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Jun 2011 17:17:55 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.193 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.193 smtp193.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.193] ([67.192.241.193:45175] helo=smtp193.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 92/20-34681-3C08FFD4 for ; Mon, 20 Jun 2011 13:17:55 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp9.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 852B03C0560; Mon, 20 Jun 2011 13:17:52 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp9.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 364F13C0545; Mon, 20 Jun 2011 13:17:51 -0400 (EDT) Message-ID: <4DFF80BF.2030300@sugarcrm.com> Date: Mon, 20 Jun 2011 10:17:51 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Robert Eisele CC: "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Standard constants as part of the lexer From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! On 6/20/11 4:12 AM, Robert Eisele wrote: > I think it depends on the experience of the developers. There are many - > halfway ugly - "PHP optimization" tricks on the net. If these are used, the > difference wouldn't that much. But constructs like for($i=0; $i $i++) could get optimized vigorous. If you're microoptimizing, you should not do this unless $x is a dynamic string, so I'm not sure messing with strlen is the right way to improve it. Also, I really do not like splitting strlen()/count() code into two places. It hurts maintainability and will lead to weird BC problems. I'm not sure if the optimization is worth it, but if it is, it should be done differently, with only one code for any strlen()/count() implementation. Also, I don't see why strlen/count should share an opcode if there's absolutely no common implementation code between them. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227