Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41737
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain tekrat.com from 69.63.177.213 cause and error)
Cc: "Lukas Kahwe Smith" <mls@pooteeweet.org>,
 "Karoly Negyesi" <karoly@negyesi.net>,
 internals@lists.php.net
Message-ID: <4022974B-4A13-4AB0-A282-973503200406@tekrat.com>
To: Graham Kelly <sgkelly4@gmail.com>
In-Reply-To: <e382ba0811050722k34c3c3e6vfe082b0a6adb1e38@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 6 Nov 2008 10:37:02 -0800
References: <7e270cea0810191211w2cb77075y5e0ad78c2f7306f7@mail.gmail.com> <243C7392-C6A0-4EE8-8AAA-34964E78D453@tekrat.com> <EC8C4CC0-4089-422B-9223-CCDD8A796341@pooteeweet.org> <e382ba0811050722k34c3c3e6vfe082b0a6adb1e38@mail.gmail.com>
Subject: Re: [PHP-DEV] An optimization idea
From: shire@tekrat.com (shire)


On Nov 5, 2008, at 7:22 AM, Graham Kelly wrote:

> Hi,
>
> I played with a patched version of compare_function with this  
> optimization in it. Other then for strings it didn't seem to make  
> much of a difference. A quick test showed that in an average php  
> application only about 0.15% of calls to compare_function actually  
> have the same op1 and op2. Considering it doesn't make much of a  
> difference for anything except string comparison (and maybe arrays?)  
> it probably isnt worth putting it in compare_function. This  
> certinally is not a common case and would only serve to add an extra  
> needless comparison and branch to the other 99% of calls to  
> compare_function. Also, it seems as if in most cases this type of  
> behavior could be detected and handled appropriatly at compile time  
> by a good optimizer.

I started looking at this briefly, and agree with what you describe  
above.  I was curious to see if anyone came back with any real world  
applications where they where hitting this scenario but it seems  
unlikely.

>
>
> However, while the common compare_function call probably wouldent  
> gain anything from this, maybe it could be put in the  
> TYPE_PAIR(IS_STRING, IS_STRING) case or put into zendi_smart_strcmp  
> (which only seems to ever be called by the TYPE_PAIR(IS_STRING,  
> IS_STRING) case of compare_function).
>
> I havent played with the patched version of zend_hash_compare to see  
> if it might provide any real world savings. Though it appears as if  
> that function might see a significant improvement for these cases.

Arrays and strings do seem to be the only real worth while comparisons  
for this type of optimization, but only because the costs of comparing  
long strings and large array lists make the savings more significant.   
I think it might be hard to see this in a real world application  
though, so it would be nice if someone could justify the change by  
showing test results.  I'll try to bench Facebook's code base to see  
what we can get out of it.

-shire