Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67309 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67345 invoked from network); 5 May 2013 13:24:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 May 2013 13:24:08 -0000 Authentication-Results: pb1.pair.com header.from=ekneuss@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ekneuss@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.181 as permitted sender) X-PHP-List-Original-Sender: ekneuss@gmail.com X-Host-Fingerprint: 209.85.216.181 mail-qc0-f181.google.com Received: from [209.85.216.181] ([209.85.216.181:40803] helo=mail-qc0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 03/64-33933-37D56815 for ; Sun, 05 May 2013 09:24:04 -0400 Received: by mail-qc0-f181.google.com with SMTP id s25so1354082qcq.40 for ; Sun, 05 May 2013 06:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=gzgXLQFXcfvibT/ygI6oEt40S9Fk8/XNH+E5glGEMd8=; b=qe04TbuMjfzX+P5Gw73xtIabEQY4Grtdx1OJOw0XJLL5wiHaguP0u9uCRkz6CzGqbO Nzo6n1QIn5ZshY+avmKwmLYv61k2K+5fIH5uQ/EEvOf+w6kyePDfIZGL+ZFaP8tYizse gUnhVu9VYUV6yEf7Uu3i5/kC1THYJ8kCxCMrUgdGmCxPTFXvvZj7Ipatb81y70/DrRME Dekmsx9eUoifbLqpYLfqE2CK4/WwxEiS8dsETRsClvbtQ1asGq9Mn5v9/rgR5icZZ9Jo jHOmpm8dilaCyP9hJtGMwsvaGfw64HnKla/E75Qm94I3AwoTFRHMXrJ7sUCafkYL2zOy N+mg== X-Received: by 10.229.158.209 with SMTP id g17mr4853190qcx.39.1367760240867; Sun, 05 May 2013 06:24:00 -0700 (PDT) MIME-Version: 1.0 Sender: ekneuss@gmail.com Received: by 10.49.87.70 with HTTP; Sun, 5 May 2013 06:23:40 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 May 2013 15:23:40 +0200 X-Google-Sender-Auth: Ir9wxMHYQHtCgea7uvrnNLJJ0g8 Message-ID: To: Laruence Cc: PHP Internals Content-Type: multipart/alternative; boundary=f46d04446b3b4b9fca04dbf87f30 Subject: Re: [PHP-DEV] Re: [PROPOSAL]Add second to callback of preg_replace_callback From: colder@php.net (Etienne Kneuss) --f46d04446b3b4b9fca04dbf87f30 Content-Type: text/plain; charset=UTF-8 On Sat, May 4, 2013 at 4:31 PM, Laruence wrote: > I made a RFC for this: > https://wiki.php.net/rfc/second_arg_to_preg_callback > > Note that giving meaning to an extra argument in existing callbacks constitutes a small BC break in at least two cases: 1) function myhandyfunction($v, $arg = 42) { .. } preg_replace_callback([..., ...], "myhandyfunction", ..) here $arg will no longer be 42 after this change. 2) Most internal functions do not accept extra arguments, and thus will suddenly raise a notice if used as callbacks. It might be worth mentionning this in the RFC. > thanks > > > > > On Sat, May 4, 2013 at 10:28 PM, Laruence wrote: > > > > > > > > > On Sat, May 4, 2013 at 9:46 PM, Anthony Ferrara >wrote: > > > >> Laruence, > >> > >> > foreach ($replacements as $regex => $callback) { > >> > > $str = preg_replace_callback($regex, $callback, $str); > >> > > } > >> > > > >> > > >> > So if there are 10 regex in the array, you will got 10 DO_FCALL. 10 > >> times > >> > arguments accept, 10 times etc... > >> > > >> > and AS I already said: IT is inefficient. I personally can not accept > >> it. > >> > > >> > thanks > >> > > >> > > >> My initial reaction was that the difference in runtime is going to be so > >> insignificant that it's the very definition of a micro-optimization > >> between > >> the two. And unless you're doing it millions of times in a hot-loop, > it's > >> never even going to be realized. I was going to reply to that effect. > >> > >> Then I decided to write a quick test. > >> > >> $count = 100; > >> > >> $start = microtime(true); > >> for ($i = 0; $i < $count; $i++) { > >> $str = "abc"; > >> $str = preg_replace_callback('/a/', function($a) { return > >> strtoupper($a[0]); }, $str); > >> $str = preg_replace_callback('/b/', function($a) { return > >> strtoupper($a[0]); }, $str); > >> $str = preg_replace_callback('/c/', function($a) { return > >> strtoupper($a[0]); }, $str); > >> $str = preg_replace_callback('/a/', function($a) { return > >> strtolower($a[0]); }, $str); > >> $str = preg_replace_callback('/b/', function($a) { return > >> strtolower($a[0]); }, $str); > >> $str = preg_replace_callback('/c/', function($a) { return > >> strtolower($a[0]); }, $str); > >> } > >> echo "Completed in " . (microtime(true) - $start) . " Seconds\n"; > >> > >> $start = microtime(true); > >> for ($i = 0; $i < $count; $i++) { > >> $str = "abc"; > >> $str = preg_replace(array( > >> '/a/e', > >> '/b/e', > >> '/c/e', > >> '/a/e', > >> '/b/e', > >> '/c/e', > >> ), > >> array( > >> 'strtoupper(\'$1\')', > >> 'strtoupper(\'$1\')', > >> 'strtoupper(\'$1\')', > >> 'strtolower(\'$1\')', > >> 'strtolower(\'$1\')', > >> 'strtolower(\'$1\')', > >> ), > >> $str > >> ); > >> } > >> echo "Completed in " . (microtime(true) - $start) . " Seconds\n"; > >> > >> So basically, it's comparing the old behavior (one call to preg_replace) > >> that you want to emulate, with what Nikita is suggesting. > >> > >> I ran it on 3v4l (http://3v4l.org/dRjtU) and the results were quite > >> surprising. I was expecting the first to be slightly slower than the > >> second. But the reality surprised me: > >> > >> Completed in 0.00076389312744141 Seconds Completed in 0.0012428760528564 > >> Seconds > >> > >> As it turns out, calling preg_replace_callback() multiple times is > almost > >> 50% faster than using a single call to preg_replace(). > >> > >> It's likely due to the precompiled nature of closures, vs the > compilation > >> happening multiple times at invocation in the preg_replace /e case. > >> > >> But it's still worth noting that switching from the /e style to a more > >> traditional preg_replace_callback implementation will get you a > >> significant > >> boost in performance of that. > >> > >> Now, keep in mind, we're talking 0.000005 seconds saved per "execution" > >> (group of 6 replacements). So it's not likely to matter much or be worth > >> worrying about... > >> > > Hey: > > thanks for the benchmark, but please don't think it's useless just > > because it's monior > > > > PHP is a web program language, let's think about a high trafiic site, > > which get 100, 000, 000 pv perday. > > > > 100, 000, 000 * 0.0000005 = 500s perday > > > > and inefficent not always means performance only, in this case , you > > need to define various functions for different regexs if you use loop > style. > > > > and do you prefer array_walk or foreach when you try to iteraterly > > process an array? > > > > > > thanks > > > >> > >> My $0.02 at least... > >> > >> Anthony > >> > > > > > > > > -- > > Laruence Xinchen Hui > > http://www.laruence.com/ > > > > > > -- > Laruence Xinchen Hui > http://www.laruence.com/ > -- Etienne Kneuss http://www.colder.ch --f46d04446b3b4b9fca04dbf87f30--