On Fri, 16 Jul 2004 12:15:46 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> On July 16, 2004 11:58 am, Thies C. Arntzen wrote:
> > 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)
>
> Recursive functions in PHP are inherently dangerous as without proper limits
> they will rather quickly ~5671 iterations with a basic function a() { a(); }
> (PHP 4/5).
> By comparison the same code only takes 2897 iterations before the patch. While
> the patch does not solve this crash it reduces it's chances by nearly 50%
> (unexpected benefit).
>
> More over the crash problem that the patch solves is not theoretical that I
> made up because I have nothing better to do. We have at least 2 confirmed bug
> reports by different people and surely there are others who came across this
> issue and didn't report it.
>
> Yes, you are correct, with a dedicated benchmark specifically designed to
> "exploit" the allocation routine change there is a performance drop, but
> surely stability is more important then speed. If that is not that case,
> there are a whole lot of optimizations we can perform, but that'd mean users
> will need to write their code extra carefully :-), which as we know is not
> going to happen.
php has no real concept for out-of-memory situations (stack or real)
- nor do we catch infinite (nor too deep) recursions. allowing for
"deeper" recursion doesn't really fix anything. so, i think we should
either come up with a real solution or leave it as it is.
i have to say that i do care if we're making the genreal case slower,
even if it's a tiny bit...
re,
-tc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
