> Actually - depending on the platform also:
What platform is this? I'm dubious of these results, given the negative
numbers for transfered bytes and transfer rate.
Also, be sure to run your tests from a different machine, and make sure
that you aren't maxing out your client.
Last note is you r
At 18:53 6-6-2002, Cliff Woolley shared with all of us:
>On Thu, 6 Jun 2002, Sebastian Bergmann wrote:
>
> > A user posted [1] a "benchmark" today in the German PHP Newsgroup [2]
> > stating that Apache 2.0 and PHP (current HEAD) are about 20% slower
> > than Apache 1.3.
> >
> > Are there
On Thu, Jun 06, 2002 at 07:18:22PM +0200, Sebastian Bergmann wrote:
> Cliff Woolley wrote:
> > Namely, we need to be able to give Zend's lexer buffers to scan rather
> > than handing it a file descriptor.
>
> Last time I talked to Zeev about this he said that this has been added.
> (Acceptin
Cliff Woolley wrote:
> Namely, we need to be able to give Zend's lexer buffers to scan rather
> than handing it a file descriptor.
Last time I talked to Zeev about this he said that this has been added.
(Accepting a buffer instead of a file handle.)
--
Sebastian Bergmann
http://sebasti
On Thu, 6 Jun 2002, Sebastian Bergmann wrote:
> A user posted [1] a "benchmark" today in the German PHP Newsgroup [2]
> stating that Apache 2.0 and PHP (current HEAD) are about 20% slower
> than Apache 1.3.
>
> Are there any official benchmarks out there? I can't quite believe
> this...
Again, I believe that's exactly the point Cris was making - running a million executions of a code block is not something which happens in real life. In practice, chances are the speed loss will be negligible in most real world situations.
I've seen code where people do things like write their ow
At 20:35 09-09-01, George Schlossnagle wrote:
>>This is just mind boggling! Sure, there's roughly
>>twice the work to call a user function wrapper compared to calling the
>>internal. There's also the loss in parsing.
>
>The parsing overhead is amortized over a million executions of the code
>bloc
By the way, I believe Cris's point was that in a real world situation, the
extra time it takes for a function call is negligible in comparison to
everything else (SQL access, startup/shutdown costs, etc.). Obviously, if
you intentionally benchmark one function call vs. two function calls,
you
