Re: New zend_compile.c to solve all of the duplicate function problems

From: 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 > > >

« previous php.dev (#68422) next »