Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39256
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.163 as permitted sender)
Message-ID: <488835D0.1040005@zend.com>
Date: Thu, 24 Jul 2008 11:57:04 +0400
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Matt Wilmas <php_lists@realplain.com>
CC: internals@lists.php.net
References: <00ea01c8a160$2edd8160$0201a8c0@pc1> <016c01c8eccd$e28cfac0$0201a8c0@pc1>
In-Reply-To: <016c01c8eccd$e28cfac0$0201a8c0@pc1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] No runtime fetching of built-in global constants
From: dmitry@zend.com (Dmitry Stogov)

Hi Matt,

Sorry if I missed it.

Does this patch make any performance difference?

I assume it saves on hash lookup during compilation and its really 
insignificant time. However it add new scanner rules which may slowdown 
the whole scanner.
For now I don't see a big reason, but may be I didn't see something.

Do you have any other "postponed" patches?
I remember something about string optimizations and long multiply.

Thanks. Dmitry.




Matt Wilmas wrote:
> Hi all,
> 
> Never heard anything about this optimization after sending it 3 months ago
> (should've sent a follow-up sooner)...
> 
> Is this something that can be done?  Dmitry?  Details in original message.
> Patch is unchanged, I just updated them for the current file versions.
> 
> http://realplain.com/php/const_ct_optimization.diff
> http://realplain.com/php/const_ct_optimization_5_3.diff
> 
> 
> Thanks,
> Matt
> 
> 
> ----- Original Message -----
> From: "Matt Wilmas"
> Sent: Friday, April 18, 2008
> 
>> Hi all,
>>
>> I changed things so that the many "built-in" constants (CONST_PERSISTENT
>> ones) will be replaced at compile-time, saving the FETCH_CONSTANT opcode,
> if
>> these changes are usable.  This was added for TRUE/FALSE/NULL 2 years ago,
>> but seems like it can be done for "lots" of others too.
>>
>> Since the change 2 years ago, other constants have been getting looked up
>> also, but just discarded.  And if a constant wasn't found, its name was
>> lowercased and looked up again (for case-insensitive TRUE/FALSE/NULL).
>> Lowercasing has been removed, since case-insensitive constants can't be
> done
>> (guess an exception was made for TRUE/FALSE/NULL :-)), and TRUE/FALSE/NULL
>> get flagged in the scanner (not reserved words, which Marcus did briefly a
>> few years ago), skipping a hash lookup.  BTW, to get this compile-time
>> optimization in a namespace, it needs to be prefixed (::CONSTANT).
>>
>> I also removed an unnecessary memcmp() in zend_get_constant() -- old code
>> that was needed a long time ago, it appears.
>>
>> http://realplain.com/php/const_ct_optimization.diff
>> http://realplain.com/php/const_ct_optimization_5_3.diff
>>
>> Thoughts?
>>
>>
>> Thanks,
>> Matt
>