Re: [ZEND-ENGINE-CVS] Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_execute.c

That is nowhere near a real-life application. There's no logic only function calls. Look, I asked Ilia not to change the alloca() but eventually agreed. So personally I have no problem with undoing that patch, but I still think that not testing real-life applications is not the way to make a case. Andi At 12:41 PM 7/16/2004 -0400, Ilia Alshanetsky wrote:

Here you go. <?php function a($m, $n) {

        if ($m == 0) return $n+1;
        if ($n == 0) return a($m - 1, 1);
        return a($m - 1, a($m, ($n - 1)));

} $n = !empty($_SERVER['argv'][1]) ? (int)$_SERVER['argv'][1] : 1; $r = a(3, $n); echo "a(3,$n): $r\n"; ?> Ilia On July 16, 2004 12:32 pm, Andi Gutmans wrote: Do you have the source? I think it'd be more interesting to see the performance difference on a real world application such as phpBB, phpnuke or similar. If you can give us numbers on that, it would definitely improve your point if the performance penalty show in that case. At 05:58 PM 7/16/2004 +0200, Thies C. Arntzen wrote:

On Fri, 16 Jul 2004 08:39:21 -0400, Ilia Alshanetsky <ilia@prohost.org>

wrote:

Oops mail client assign the message to the wrong patch. In response to Andi's question, we can probably get away with using a

regular

malloc since the number of variables needed to cause a crash will probably cause a memory exhaustion way earlier. As for performance impact, it's soo insignificant it's hardly worth mentioning, feel free to benchmark.

hey ilia, here's another one of my meaningess, synthetic benchmarks (this is how the CreatorsOfPHP(tm) would call them) ackermann(8) (source on request - highly recursive) after your patch: 13,63 sec before your patch : 11,86 sec re, tc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php