Hi,
I've just rerun some synthetic and real-life benchmarks.
All the test were run on the same box (Linux, Core2 Duo 3GHz, 4GB RAM).
5.3 and 5.4 where configured and build with the same options and ran as
FastCGI server with the same number of processes and set of extensions.
PHP performance
On Mon, Feb 6, 2012 at 1:03 AM, Christopher Jones
wrote:
> Windows PHP 5.4 is built using profile-guided optimizations, but
> PHP 5.3 isn't. My reading of Pierre's own benchmarks are that this
> seems to be contributing significantly to the 5.4 gains on Windows.
> It makes Windows a poor platfor
On Sun, Feb 5, 2012 at 19:32, Adam Harvey wrote:
> On 6 February 2012 04:37, Tom Boutell wrote:
>> Deprecate and then remove, or just leave it in. "Make it optional
>> forever" just generates more nonportable PHP code. Ick.
> Huge +1 to that.
> Given the existence of preg_replace_callback() (as S
On Sun, Feb 5, 2012 at 17:08, Stas Malyshev wrote:
> Hi!
>
> Another thing - is there any way to give CLANG some hints about some
> functions - such as the fact that zend_error(E_ERROR) does not return or
> just make some exceptions when we know some situation that it thinks can
> happen does not
On 6 February 2012 04:37, Tom Boutell wrote:
> Deprecate and then remove, or just leave it in. "Make it optional
> forever" just generates more nonportable PHP code. Ick.
Huge +1 to that.
Given the existence of preg_replace_callback() (as Stas noted above),
my preference is for deprecation and t
On 2/5/12 10:26 AM, Timm Friebe wrote:
Hi,
As many of you know we made huge improvements in PHP 5.4 memory usage
(enabling higher concurrency) and runtime performance.
Here are the unit test results for https://github.com/xp-framework/xp-framework
and https://github.com/xp-framework/xp-lan
On Sun, 05 Feb 2012 14:08:17 -0800, Stas Malyshev wrote:
Another thing - is there any way to give CLANG some hints about some
functions - such as the fact that zend_error(E_ERROR) does not return
or just make some exceptions when we know some situation that it
thinks can happen does not in fact h
You cannot use Travis CI to compare for runtime of php5.4 and 5.3 since the
used boxes are propably either different and also under high load due to
virtualization, but you can check for memory differences. And they are huge:
Doctrine 2:
5.3: http://travis-ci.org/#!/doctrine/doctrine2/jobs/593850
Hi!
Another thing - is there any way to give CLANG some hints about some
functions - such as the fact that zend_error(E_ERROR) does not return or
just make some exceptions when we know some situation that it thinks can
happen does not in fact happen - such as revtal_ptr_ptr = &retval_ptr
and
Am 05.02.2012 21:34, schrieb Jaroslav Hanslik:
> PHP 5.3.10 - Total time: 777 seconds, used: 316 MB RAM
> PHP 5.4.0RC7 - Total time: 452 seconds, used: 156 MB RAM
phpDox, initial run for Zend Framework 2
PHP 5.4: Time: 54 seconds, Memory: 30.50Mb
PHP 5.3: Time: 01:09, Memory: 42.25Mb
Deprecate and then remove, or just leave it in. "Make it optional
forever" just generates more nonportable PHP code. Ick.
On Sun, Feb 5, 2012 at 3:28 PM, Stas Malyshev wrote:
> Hi!
>
>
>> Removing this would obviously be an inconvenience for some people,
>> but getting your server hacked is also
As many of you know we made huge improvements in PHP 5.4 memory usage (enabling
higher concurrency) and runtime performance.
We've done our own benchmarks but it'd be great to hear from others re: what
you're seeing with your real-world apps.
Zend Framework API documentation generated by
Hi!
Removing this would obviously be an inconvenience for some people,
but getting your server hacked is also an inconvenience, and hackers
don't give you nice warnings with file and line number. I like the
idea of doing _something_ here. Deprecate now and remove later sounds
fair.
Inconvenien
Hi!
That sounds like a nicer approach and it is actually one of the RFC I
like to see to bring some of the features of Suhosin in PHP (disable
eval and the e modifier).
Disbaling eval() makes little sense to me - nobody accidentally writes
an eval() and if you execute third-party code there's
Hi,
> As many of you know we made huge improvements in PHP 5.4 memory usage
> (enabling higher concurrency) and runtime performance.
Here are the unit test results for https://github.com/xp-framework/xp-framework
and https://github.com/xp-framework/xp-language after applying workarounds for
tw
hi,
On Sun, Feb 5, 2012 at 5:45 PM, Michael Stowe wrote:
> Perhaps another option, if it's a security concern is the ability to turn off
> the /e modifier, and have it off by default. This way we can protect our less
> experienced programmers, while keeping it available for more advanced use
Am 05.02.2012 18:09, schrieb Nikita Popov:
> On Sun, Feb 5, 2012 at 5:45 PM, Michael Stowe wrote:
> [snip]
>> Perhaps another option, if it's a security concern is the ability to turn
>> off the /e modifier, and have it off by default. This way we can protect our
>> less experienced programmer
On Sun, Feb 5, 2012 at 5:45 PM, Michael Stowe wrote:
[snip]
> Perhaps another option, if it's a security concern is the ability to turn off
> the /e modifier, and have it off by default. This way we can protect our less
> experienced programmers, while keeping it available for more advanced use
> -Original Message-
> From: Derick Rethans [mailto:der...@php.net]
> Sent: Sunday, February 05, 2012 11:46 AM
> To: Nikita Popov
> Cc: PHP internals
> Subject: Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from
> preg_replace
>
> On Sun, 5 Feb 2012, Nikita Popov wrote:
>
> > I h
On Sun, Feb 5, 2012 at 5:21 PM, Pierre Joye wrote:
> hi,
>
> I think we should remove eval at the same time then. As the risk is
> exactly the same in both situations. Eval is just as evil and can be
> avoided as well (or any other similar features, not sure if other exts
> allow that).
>
> Cheer
Am 05.02.2012 17:45, schrieb Michael Stowe:
> Perhaps another option, if it's a security concern is the ability
> to turn off the /e modifier, and have it off by default. This way
> we can protect our less experienced programmers, while keeping it
> available for more advanced use cases.
>
>
On Sun, 5 Feb 2012, Tom Boutell wrote:
> A sense of humor is important when reading mailing lists frequented by
> extremely clever people (:
Sarcasm doesn't work on mailinglists, so don't use it.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xde
On Sun, 5 Feb 2012, Nikita Popov wrote:
> I have written an RFC that proposes to *deprecate* and *remove* the /e
> modifier:
>
> https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
>
> Comments welcome!
This RFC makes no sense. It says:
For example the above example can be used to exec
Perhaps rather than killing it we should just emphasize it more in the
documentation (ie on preg_replace and not only in pattern modifiers).
But I have found the /e modifier to be very useful in the past. Unfortunately,
just having woken up I can't remember exactly where and how I used it, lol.
i did not see any smiley and without it is hard to smell
remove /e makes sense over the long because it is
really dangerous to get wrong used with user-input
by pepole C&P reg-expressions from somewehre without exactly
understand what they are doing and that they can trigger
remote-code execution
A sense of humor is important when reading mailing lists frequented by
extremely clever people (:
On Sun, Feb 5, 2012 at 11:34 AM, Reindl Harald wrote:
> what he hell - if you kill eval you would kill the whole
> work of my life and yes i know that eval is evil and
> it is only used at one place
On Sun, Feb 5, 2012 at 5:23 PM, Rasmus Lerdorf wrote:
> On 02/05/2012 02:49 AM, Ferenc Kovacs wrote:
> > Hi Rasmus,
> >
> > I see that you are fixing tests in the 5.4 branch, however I was told by
> > Stas that I should hold my test fixes until the release:
> > http://www.mail-archive.com/interna
what he hell - if you kill eval you would kill the whole
work of my life and yes i know that eval is evil and
it is only used at one place which is a central and
real important to include modules and set parameters
dynamically
the /e modifier is a total other dimension because it can
be used by pe
I know a straw man argument when I see one (:
/e suggests that eval is a casual thing to be sprinkled into typical
search and replace operations. It also suggests that putting PHP code
in a quoted string is probably the easy way to solve your problem.
It's often discovered before the developer has
hi,
I think we should remove eval at the same time then. As the risk is
exactly the same in both situations. Eval is just as evil and can be
avoided as well (or any other similar features, not sure if other exts
allow that).
Cheers,
On Sun, Feb 5, 2012 at 3:59 PM, Nikita Popov wrote:
> Hi inter
I think this is a good idea, since nobody's keeping you from calling
eval() in a callback if you really really really need to, there's no
loss of functionality, just the discouragement of an unhealthy "worst
practice." (:
On Sun, Feb 5, 2012 at 9:59 AM, Nikita Popov wrote:
> Hi internals!
>
> I h
Hi internals!
I have written an RFC that proposes to *deprecate* and *remove* the /e modifier:
https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
Comments welcome!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sat, Feb 4, 2012 at 8:20 PM, Clint Byrum wrote:
hi,
> So, I think I could probably put myself in as somebody that would support
> an effort to bring Suhosin's mitigations into PHP core. I don't know
> that the greater Ubuntu roject could devote many man-hours to it, but
> perhaps I could write
33 matches
Mail list logo
