Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70276
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.52 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAHMUw2HtaCKPd+2vqeG4_0TdET=O35AAyBhif+FC4JndZLRJEw@mail.gmail.com>
References: <BLU0-SMTP3754E6EDF4B68C55DC96C21E2E60@phx.gbl>
 <CAGa2bXZUSV-xCHm0cSUuPmcv6RzzGHL61qHwQ87w7kCGrOvH7A@mail.gmail.com>
 <BLU0-SMTP17B09A3D7BD4EEF1AF7384E2E60@phx.gbl> <CAGa2bXac2SWLo8kR1Nnatj9k9ZQ8rs7A4hSatLS1uFp_FArp-Q@mail.gmail.com>
 <BLU0-SMTP1872D2BA1EF2A5755133BB9E2E60@phx.gbl> <CAGa2bXYmV3+BuowZTBdQjgGoWqiZhYegd8w5208Mso5SAoq=Ew@mail.gmail.com>
 <CAGa2bXZht4UcArRqxr255bfV4jsW1B4Q8OJHhKANRiwS_8f+rQ@mail.gmail.com>
 <CAGa2bXYXHz8YXOBoBK14xhCJy26e=-g0O496_gSRxQmqb3ieCA@mail.gmail.com> <CAHMUw2HtaCKPd+2vqeG4_0TdET=O35AAyBhif+FC4JndZLRJEw@mail.gmail.com>
Date: Fri, 22 Nov 2013 14:11:25 +0900
Message-ID: <CAGa2bXaFMPaDp51Fz_gEV_qAmeXguCa0jRzVTbm7xLhc=VmDFQ@mail.gmail.com>
To: Tjerk Meesters <tjerk.meesters@gmail.com>
Cc: Bob Weinand <bobwei9@hotmail.com>, List PHP Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b3432b6261d6804ebbd0ecc
Subject: Re: [PHP-DEV] [RFC] [VOTE] Constant scalar expressions
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--047d7b3432b6261d6804ebbd0ecc
Content-Type: text/plain; charset=UTF-8

Hi Tjerk,

On Fri, Nov 22, 2013 at 1:34 PM, Tjerk Meesters <tjerk.meesters@gmail.com>wrote:

> Yes, of course that's all possible, because define() is just a function
> and therefore the normal assignment rules apply. However, you didn't
> mention the biggest drawback to such an approach, which is that it creates
> *global* constants; there's no way to namespace them.
>

What was the reason why we don't have name space for define()?


>> I prefer 'const' to be a static for better performance, since
>> we have dynamic constant by define() already.
>>
>
> Perhaps we'd have to consider how much performance is impacted on existing
> code, e.g.
>
>     class A
>      {
>         const B = 123;
>     }
>
> How much slower would that become if this RFC is accepted, cached or
> otherwise?
>

I made a script to experiment. I have background job running on this
machine,
so I don't get stable result now, but embedding value is constantly faster.

[yohgaki@dev tmp]$ php bench.php
Time: 6.4675929546356
Time: 7.4527719020844 15.232544075653% slower
Time: 7.4178550243378 14.69266968975% slower
Time: 8.1120491027832 25.426092205894% slower
Time: 7.4948840141296 15.883669035753% slower
[yohgaki@dev tmp]$ php bench.php
Time: 6.4104981422424
Time: 7.7053151130676 20.198383060014% slower
Time: 8.022579908371 25.14752723358% slower
Time: 7.5032601356506 17.046444272519% slower
Time: 7.713919878006 20.332612331241% slower

[yohgaki@dev tmp]$ cat bench.php
<?php
define('a', 1);
const b = 1;

class foo {
const c = 1;
}

class bar extends foo {};

$start = microtime(true);
for ($i=0 ; $i < 99999999; $i++) {
 $v = 1 + 1;
}
$test0 = microtime(true) - $start;
echo 'Time: '. $test0 . PHP_EOL;

$start = microtime(true);
for ($i=0 ; $i < 99999999; $i++) {
$v = 1 + a;
}
$test = microtime(true) - $start;
echo 'Time: '. $test . ' '. (($test - $test0)/$test0)*100 . '% slower' .
PHP_EOL;

$start = microtime(true);
for ($i=0 ; $i < 99999999; $i++) {
    $v = 1 + b;
}
$test = microtime(true) - $start;
echo 'Time: '. $test . ' '. (($test - $test0)/$test0)*100 . '% slower' .
PHP_EOL;

$start = microtime(true);
for ($i=0 ; $i < 99999999; $i++) {
$v = 1 + foo::c;
}
$test = microtime(true) - $start;
echo 'Time: '. $test . ' '. (($test - $test0)/$test0)*100 . '% slower' .
PHP_EOL;

$start = microtime(true);
for ($i=0 ; $i < 99999999; $i++) {
$v = 1 + bar::c;
}
$test = microtime(true) - $start;
echo 'Time: '. $test . ' '. (($test - $test0)/$test0)*100 . '% slower' .
PHP_EOL;
?>

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--047d7b3432b6261d6804ebbd0ecc--