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 <[EMAIL PROTECTED]> 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
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
