Funny, it's in the message my mua said it sent (the 2nd time). How is
this?
It's also in pear/PECL/optimizer/zend.patch
On Sunday, November 10, 2002, at 06:11 AM, Derick Rethans wrote:
On Sat, 9 Nov 2002, George Schlossnagle wrote:
Hehe. I should attach the patch, eh?
Yes, you shoul
On Sat, 9 Nov 2002, George Schlossnagle wrote:
> Hehe. I should attach the patch, eh?
Yes, you should... but you still didn't do that :-)
Derick
--
---
Derick Rethans http://derickretha
Hehe. I should attach the patch, eh?
On Saturday, November 9, 2002, at 09:15 PM, George Schlossnagle wrote:
Here's the patch that Dan and I put together for the optimizer we
talked about at the conference. It basically provides a
defaulted-to-null function pointer that is the default case
Here's the patch that Dan and I put together for the optimizer we talked
about at the conference. It basically provides a defaulted-to-null
function pointer that is the default case for the main execute() loop.
This allows people to define their own opcodes without having to copy
the source c
> On Fri, Nov 08, 2002 at 04:17:43PM -0500, Andrei Zmievski wrote:
>
> > I've made a small patch that turns strlen() into a statement executed by
> > the engine instead of a function. The reasoning is that something that
> > integral should probably be in the engine. I haven't done hard
> > benchm
On Fri, Nov 08, 2002 at 04:17:43PM -0500, Andrei Zmievski wrote:
> I've made a small patch that turns strlen() into a statement executed by
> the engine instead of a function. The reasoning is that something that
> integral should probably be in the engine. I haven't done hard
> benchmarking but i
Do you think strlen() is actually called that often? And isn't it a
relatively quick function as it is? Just seems like you are optimizing a
function that isn't actually called that often and when it is called
having a 25% speedup on a function that takes a tiny fraction of the
overall execution
At 05:18 PM 11/8/2002 -0500, Andrei Zmievski wrote:
On Sat, 09 Nov 2002, Andi Gutmans wrote:
> I am very much against anything like this.
> Improving strlen()'s performance only will have a negligible performance
> impact on a real world script.
> With the same kind of argument you could probably
On Sat, 09 Nov 2002, Andi Gutmans wrote:
> I am very much against anything like this.
> Improving strlen()'s performance only will have a negligible performance
> impact on a real world script.
> With the same kind of argument you could probably find 10-20 functions
> which would be faster if you
Hi,
I am very much against anything like this.
Improving strlen()'s performance only will have a negligible performance
impact on a real world script.
With the same kind of argument you could probably find 10-20 functions
which would be faster if you'd make opcodes for them. That's not really
w
I've made a small patch that turns strlen() into a statement executed by
the engine instead of a function. The reasoning is that something that
integral should probably be in the engine. I haven't done hard
benchmarking but it seems to improve performance of that particular
piece of code by about 2
11 matches
Mail list logo