Re: New zend_compile.c to solve all of the duplicate function problems
| From: | Brian Moon | Date: | Fri, 19 Oct 2001 15:47:39 +0000 |
| Subject: | Re: New zend_compile.c to solve all of the duplicate function problems | ||
| References: | 1 2 3 4 5 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-68422@lists.php.net to get a copy of this message | ||
It is in fact slightly faster. I created a script with 100000 functions
like:
function foo1() { echo 1; }
It was 3.3 seconds to 3.6 seconds in favor of the patched code.
It handles Bug #9884 because functions are never added to the function table
twice. As of right now they are. In the RC they are added and then an
ERROR is raised.
Brian.
----- Original Message -----
From: "Edin Kadribasic" <edink@proventum.net>
To: "Brian Moon" <brianm@dealnews.com>; "Daniel Beckham"
<danbeck@dealnews.com>
Cc: "PHP Development" <php-dev@lists.php.net>
Sent: Friday, October 19, 2001 9:48 AM
Subject: Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate
function problems
> > The problem is backward compatiblity. That is the biggest thing at
stake
> > here. Daniel and I are a bit skewed as we have over 1000 files full of
> code
> > that start with something like:
> >
> > if(defined("_FILE_NAME")) return;
> > define("_FILE_NAME", 1);
> >
> > This was our solution _before_ include_once ever existed to keep files
> from
> > being included more than once. We now know that it is in fact just not
> > executed.
>
> I was not aware of this.
>
> > Our hope is to keep the old behaviour in tact for these cases where it
is
> a
> > valid solution. The patch I sent will now allow a function to be
> redeclared
> > ever, and it will raise an ERROR if the function is being declared in a
> > different location than it has alread been encountered.
>
> Did you measure the performance impact of your patch? If it does not slow
> the engine significantly, then including it makes perfect sense. How does
it
> handle case described in bug #9884?
>
> Edin
>
>
>