Gwynne Raskind | 1 Apr 01:28 2008

Re: [PHP-DEV] PHP 5.3 the slowest PHP of all times ?!?

On Mar 31, 2008, at 5:41 PM, Benjamin Schulz wrote:
>>> This commit is responsible for the bad performance:
>>> http://cvs.php.net/viewvc.cgi/php-src/configure.in?r1=1.579.2.52.2.77.2.11&r2=1.579.2.52.2.77.2.12&diff_format=u
>> -gstabs versus -g should have no effect on production performance.
>
> Ok, maybe i made a mistake, that's what i compared:

Upon investigation I've discovered the problem to be this: When the  
Darwin hack takes effect, the overwrite of CFLAGS removes the default - 
O2, thus the slowdown. I'll commit a fix shortly, with apologies for  
the oversight.

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Derick Rethans | 1 Apr 09:42 2008
Picon
Picon

Re: Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /win32/build config.w32

On Mon, 31 Mar 2008, Marcus Boerger wrote:

> Monday, March 31, 2008, 5:09:23 PM, you wrote:
> 
> > On Mon, 31 Mar 2008, Marcus Boerger wrote:
> 
> >>   this doesn't work! When allowing to wotk with 0.13.3 then you will end up
> >> in a broken .c. Since we have the stuff checked in there really is no need
> >> at all to rengeneerate them atm.
> 
> > I found out that it does not work, but it *HAS* to work for snapshots. 
> > Please either revert the changes to PHP, or make an re2c release that 
> > can generate proper files.
> 
> That is not going to happen if no one cares about creating zend multibyte
> tests. Or we decide on getting rid of that stuff. Because obviously no on
> ecares about it anyway.

Huh, that does not make sense. If you have a version in SVN that can 
generate the correct files, how hard is it to make a release out of 
that? What does it have to do with other missing functionality?

regards,
Derick

--

-- 
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

(Continue reading)

Mario Brandt | 1 Apr 10:57 2008

RE: [PHP-DEV] PHP 5.3 the slowest PHP of all times ?!?

Hi,
I made some benchmarking on XP Pro.
The new PHP is not always faster, but over all.

Mario

PHP 5.2.5

Benchmark           Time          Peak Memory    Peak Memory (Real)
-------------------------------------------------------------------
./benchmarks\ackermann        2.222         678144         786432
./benchmarks\array            0.069         6587536        6815744
./benchmarks\array2           0.059         6594896        6815744
./benchmarks\array3           0.873         369280         524288
./benchmarks\fibonacci        4.427         81648          262144
./benchmarks\hash             0.157         3925968        3932160
./benchmarks\hash2            0.131         149416         262144
./benchmarks\heapsort         0.435         1644880        1835008
./benchmarks\mandel           1.472         88480          262144
./benchmarks\mandel2          1.764         84752          262144
./benchmarks\matrix           0.358         361936         524288
./benchmarks\nestedloop       0.781         84656          262144
./benchmarks\sieve            0.489         1408008        1572864
./benchmarks\simple           0.441         81664          262144
./benchmarks\simplecall       0.737         80456          262144
./benchmarks\simpleucall      1.268         81144          262144
./benchmarks\simpleudcall     1.669         81304          262144
./benchmarks\strcat           0.067         861880         1310720

php5.3-win32-200804010830
(Continue reading)

Pierre Joye | 1 Apr 12:51 2008
Picon

Re: cvs: php-src(PHP_5_3) / acinclude.m4

On Tue, Apr 1, 2008 at 12:02 PM, Marcus Boerger <helly <at> php.net> wrote:
> Hello Derick,
>
>
>  Tuesday, April 1, 2008, 9:41:08 AM, you wrote:
>
>  > On Mon, 31 Mar 2008, Marcus Boerger wrote:
>
>  >>   we are relying on it as only current HEAD of re2c can actually build the
>  >> language parser. At the current stage there is noone that must build the
>  >> language scanner. If so you need to install it from re2c's trunc. Otherwise
>  >> you can just take the generated .c files from our CVS.
>
>  > Like I said, the snapshot builds DO always regenerte those files - and
>  > they can't know because there is no released version of re2c to do so.
>  > And obviously we're not going to install non-released software on our
>  > production machines. So *please* make a release so that we can have
>  > snapshots again!
>
>  In this case we need to prevent snaps from using the -g flag! Which is
>  actually the default, unless someone configures to enable it. So we might
>  want to add a note about this.

To make a long story short: What prevent you to fire this release?
Even as beta? That's all we need.

--

-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

(Continue reading)

Steph Fox | 1 Apr 14:26 2008

Re: [PHP-DEV] The Untouchables

Hi Philip,

> Recently the pecl/muscat documentation was removed from phpdoc CVS. No 
> horse mouth was involved, but it seemed like a good time.

Just recording this to eliminate the bus factor. For the 'dead extensions' 
page in the manual:

The replacement for the PHP interface to the muscat search engine is 
available from http://www.xapian.org/download.php (in xapian-bindings).
Xapian is listed/linked in the 'real' current PHP manual - the one everybody 
uses as opposed to the one under development - as the replacement for 
muscat.

There's no known replacement for SMBC.

- Steph

> Regards,
> Philip
> 

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Steph Fox | 1 Apr 14:50 2008

[PHP-DEV] Re: [PECL-DEV] Re: [PHP-DEV] The Untouchables

Hi all,

> No need to wait, if the code is under GPL and still there, it must be
> moved out from CVS (both never had a pecl release so it is half of an
> issue). Let say we can move it as soon as the siberia top level module
> is in place.

OK, I heard from the muscat author. Both GPL'd extensions can be disappeared 
now. Daffodil's still on hold pending the outcome of a meeting.

So - plain old CVS attic or 'siberia' for the GPL'd ones?

- Steph 

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Marcus Boerger | 1 Apr 15:00 2008
Picon
Picon

[PHP-DEV] Re: [PECL-DEV] Re: [PHP-DEV] The Untouchables

Hello Steph,

Tuesday, April 1, 2008, 2:50:51 PM, you wrote:

> Hi all,

>> No need to wait, if the code is under GPL and still there, it must be
>> moved out from CVS (both never had a pecl release so it is half of an
>> issue). Let say we can move it as soon as the siberia top level module
>> is in place.

> OK, I heard from the muscat author. Both GPL'd extensions can be disappeared
> now. Daffodil's still on hold pending the outcome of a meeting.

> So - plain old CVS attic or 'siberia' for the GPL'd ones?

IMO Attic.

Best regards,
 Marcus

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Antony Dovgal | 1 Apr 15:02 2008

Re: [PHP-DEV] Re: [PECL-DEV] Re: [PHP-DEV] The Untouchables

On 01.04.2008 17:00, Marcus Boerger wrote:
>> So - plain old CVS attic or 'siberia' for the GPL'd ones?
> 
> IMO Attic.

Yep, attic should be fine.

--

-- 
Wbr, 
Antony Dovgal

Steph Fox | 1 Apr 15:21 2008

Re: [PHP-DEV] Re: [PECL-DEV] Re: [PHP-DEV] The Untouchables

> On 01.04.2008 17:00, Marcus Boerger wrote:
>>> So - plain old CVS attic or 'siberia' for the GPL'd ones?
>>
>> IMO Attic.
>
> Yep, attic should be fine.

I agree with you both (consider it done).
We'll need siberia for modules that have the potential to live again - these 
two aren't in that category.

- Steph 

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Pierre Joye | 1 Apr 15:25 2008
Picon

Re: [PHP-DEV] Re: [PECL-DEV] Re: [PHP-DEV] The Untouchables

On Tue, Apr 1, 2008 at 3:21 PM, Steph Fox <steph <at> zend.com> wrote:
> > On 01.04.2008 17:00, Marcus Boerger wrote:
>  >>> So - plain old CVS attic or 'siberia' for the GPL'd ones?
>  >>
>  >> IMO Attic.
>  >
>  > Yep, attic should be fine.
>
>  I agree with you both (consider it done).
>  We'll need siberia for modules that have the potential to live again - these
>  two aren't in that category.

Siberia was meant for dead module with no potential to come back to
live. I can't see how these two can live again as they are under GPL,
unless the original authors agree to relicense them.

The unmaintained packages (which can be maintained again, aka back to
live) has be marked as such.

That reminds me that I have to update the RFC according to our discussions :P

Cheers,
--

-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org


Gmane