Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

[Levi Morrison]

> We should be deprecating this alternative syntax instead of recommending
> its use. I was under the impression that we *were* already discouraging its
> use and it has already been temporarily deprecated.

I agree with Nikita. I think we should be deprecating and removing
`{}` access in favor of `[]`.

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

[PHP-DEV] Re: RFC Operator Overloading in Userspace

[Stephen Coakley]

On Mon, 04 Jan 2016 16:34:21 +, Andrea Faulds wrote:

> Hi Sara,
> 
> Sara Golemon wrote:
>> Patricio Tarantino has asked me to help him propose Operator
>> Overloading in PHP 7.1 (based in part on my operator extension in
>> PECL).  I think we can expose this to usespace as magic methods with
>> very little overhead (the runtime check and dispatch is already there,
>> after all).
>>
>> I do think that the "Future Expansion" section bears following through
>> with as well, but the basic set of methods already hooked for GMP would
>> be a nice start.
>>
>> https://wiki.php.net/rfc/operator-overloading
> 
> While I would like to see operator overloading in PHP, I don't
> particularly like the approach this RFC takes. It seems to take the
> approach C++, Python and so on use where you can simply overload any
> operator as you see fit. While that is arguably useful, it is open to
> abuse. In C++, for example, you can join two file paths by dividing
> them, or write to a stream by bitwise shifting it left by another
> stream. In Python, you repeat a string by finding the product of it and
> an integer. Abusing operator overloading like this harms readability, is
> not necessarily intuitive and is anyway unnecessary: a function or
> method would work just as well in these situations. Also, I'm not sure
> it's a good fit for a dynamic language to make operators do different
> things depending on their operand types. That just creates the
> possibility of unpleasant surprises at runtime, and PHP has enough of
> these already without the possibility of users creating more.
> 
> Luckily, C++ and Python's approach is not our only option. I am quite a
> fan of Haskell's approach to operator overloading, which is less prone
> to abuse. In Haskell, a purely-functional programming language, certain
> operators (and also certain math functions like abs()) are defined as
> part of "typeclasses", somewhat akin to interfaces in classical
> object-oriented languages like Java or PHP. These typeclasses group
> related operations together, and a conforming implementation of that
> typeclass must implement all the operations. For example, there is a
> `Num` typeclass[0] for numbers, which defines the addition, subtraction,
> multiplication, negation, absolute value, sign and
> conversion-from-integer operations. Extending `Num`, there is a
> `Fractional` typeclass[1] for fractional number types, which adds
> fractional division, reciprocal and conversion-from-rational operations.
> There are likewise similar typeclasses for non-numbers, and other
> descendents of `Num` for other kinds of numbers. The approach Haskell
> takes here is not as prone to abuse because you cannot simply implement
> operations as you please: you must implement them as a set. (Though,
> granted, Haskell also discourages overloading abuse by actually letting
> you define custom operators.) With this approach Haskell also achieves
> something else useful, in that you can use typeclasses as a type
> constraint on function parameters and return types. I think it would be
> more worth pursuing a Haskell-style approach in PHP, most likely with a
> hierarchy of magic interfaces.
> 
> All that aside, I have some other issues with the RFC. The set of
> overloadable operators proposed is very small, and I'm surprised it
> doesn't even include the full set of number operations. But
> additionally, if you were to fill in that set, I wonder if it might be
> worthwhile making some of the math functions overloadable as well, since
> otherwise you have an incomplete set of operators: %'s complement is
> intdiv(), not /, and the closest thing we have to a complement of / is
> fmod(). Likewise, since abs() works on integers and floats, perhaps it
> should work on all number types. I don't think GMP currently overloads
> any of these, though, and there is the possibility we might create
> confusion if overloading extended to math functions.
> 
> Another concern I have is the possibility of having __assign_*
> overloads. These would useful for avoiding having to instantiate a new
> object, but there's potential for them to be implemented wrongly, or be
> implemented without their corresponding normal operations. Since we
> don't have any way to make PHP 4-style copy-on-write value classes at
> the moment, I think we should just do the simpler thing and assume we're
> dealing with completely immutable objects, and therefore not have
> __assign_* methods. Similarly, I don't think should have overloads for
> ++ and -- (the proposed /__(post|pre)_(inc|dec)/ methods). Heck, they're
> probably not even that useful, because you could simply check in __add
> or __sub if the operand's absolute value is 1.
> 
> Regarding the possibility of comparison operators, again I think we
> should go the simpler route. For <, <=, >, and >=, we only need one
> overload method, perhaps __cmp, which returns the usual negative, zero
> or positive value to indicate ordering. I can't see a 

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

[Stanislav Malyshev]

Hi!

> I strongly disagree with this. $str[$offset] is well-recognized,
> generally understood syntax that does not require familiarity with
> language peculiarities. $str{$offset} might be clear to a Perl
> programmer, but to anyone else this is just guesswork, with a typo being
> a reasonable assumption.

The problem is that while it is generally understood, it's generally
understood wrongly. $str[$offset] is not the same operation as
$array[$offset]. There are many subtle differences. So while at the
first sight it's similar, it leads to "understanding" that is only going
to harm one in the future, when it turns out you really had wrong idea.
I think it's much better to instill the right idea from the start, even
if it means one has to take a brief look in the manual. String offset is
*not* the same as array access.

> We should be deprecating this alternative syntax instead of recommending
> its use. I was under the impression that we *were* already discouraging
> its use and it has already been temporarily deprecated.

I think deprecating it was a mistake and give how much semantic load []
carries - array access, array constructor, now there's proposal to make
it used in deconstructing too - adding string offset to it looks like
bad idea. Different things should use different syntax, as much as possible.

-- 
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Re: RFC Operator Overloading in Userspace

[Andrea Faulds]

Hi Stephen,

Stephen Coakley wrote:


It looks like I'm late to the party for this discussion, but I feel like
this is a similar concept to the already existing Comparable RFC , which in my opinion, has a much better
interface. Is this slightly more in-line with what you're thinking with
type classes?

I'd say this RFC should address the Comparable RFC since they are in
direct "conflict" (not quite the right word there). Perhaps instead group
relevant operators into magic interfaces like Comparable, Arithmetic, or
something along those lines.

I'm in favor of operator overloading, but it really needs to be done with
much care.



Yes, the Comparable interface is the sort of thing I'm thinking about. 
Doing things with interfaces isn't really a terribly novel idea anyway, 
it's what we already do for ArrayAccess and such.


Thanks.

--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

[Björn Larsson]

Den 2016-02-01 kl. 22:06, skrev Stanislav Malyshev:
> Hi!
> 
>> I strongly disagree with this. $str[$offset] is well-recognized,
>> generally understood syntax that does not require familiarity with
>> language peculiarities. $str{$offset} might be clear to a Perl
>> programmer, but to anyone else this is just guesswork, with a typo being
>> a reasonable assumption.
> 
> The problem is that while it is generally understood, it's generally
> understood wrongly. $str[$offset] is not the same operation as
> $array[$offset]. There are many subtle differences. So while at the
> first sight it's similar, it leads to "understanding" that is only going
> to harm one in the future, when it turns out you really had wrong idea.
> I think it's much better to instill the right idea from the start, even
> if it means one has to take a brief look in the manual. String offset is
> *not* the same as array access.
> 
>> We should be deprecating this alternative syntax instead of recommending
>> its use. I was under the impression that we *were* already discouraging
>> its use and it has already been temporarily deprecated.
> 
> I think deprecating it was a mistake and give how much semantic load []
> carries - array access, array constructor, now there's proposal to make
> it used in deconstructing too - adding string offset to it looks like
> bad idea. Different things should use different syntax, as much as possible.
> 

Yup, you do have a good point here.

Regards //Björn Larsson

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

[PHP-DEV] Re: [RFC] Warn about invalid strings in arithmetic (moving back todiscussion)

[Andrea Faulds]

Hi everyone,

There is one unresolved issue with the current patch that the RFC 
doesn't address, so I'll ask about it here.


As part of supporting exponent notation in all remaining integer 
operations (casts, operators), I would like to have intval() support it, 
to match the `(int)` cast.


For strings, intval() doesn't use the normal zval-to-long conversion 
functions (zval_get_long/convert_to_long), but instead uses strtol 
directly. This is so it can support multiple bases, e.g. intval("10", 
12) results in 12.


In order for intval() to support exponent notation, I'd have to change 
it to now call zval_get_long, but that function doesn't support 
non-decimal bases, nor does is_numeric_string_ex, which underlies it.


So, we'd either have to make intval() only support exponent notation for 
base 10, an unfortunate inconsistency, or we could not touch intval(), 
but then intval($a, 10) would no longer act the same as (int)$a.


I'm leaning towards the first choice, but I'd like to hear what the 
mailing list thinks. Either way we have a new inconsistency. But then, 
intval() has unfortunate behaviour with its base parameter anyway, in 
that ignores the base for non-string input. That means that intval(123, 
8) and intval("123", 8) aren't equivalent, a violation of weak typing.


Anyway, please tell me your thoughts.

Thanks.

--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

[Julien Pauli]

On Sun, Jan 31, 2016 at 11:14 PM, Stanislav Malyshev
 wrote:
> Hi!
>
>> The only concern I have is that support of negative indexing will break
>> symmetry with (proper) arrays, where we cannot support negative indexing.
>
> I think that was the main source of objections to this proposal in the
> past. However, as one might say, string offsets are already not
> symmetrical to array offsets - e.g. you can do $array["foo"] but not
> $string["foo"].
>
>> However this is unlikely to be a significant issue. (I do however play with
>> the thought of reutilizing the obsolete {} indexing syntax to act as offset
>> indexing instead.)
>
> I think it may be a good idea to start recommending using {} for string
> offsets and [] for arrays. While both syntaxes may work for strings, the
> intent (and expected handling of negatives, in this case) is much
> clearer when different syntax is used.

I totally agree here, having 2 different syntaxes for 2 different ways of using
the array for strings is pretty nice.


Julien

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

RE: [PHP-DEV] Re: Streams and I/O refactoring approach

[Anatol Belski]

Hi Dmitry,

Many thanks for the comments.

> -Original Message-
> From: Dmitry Stogov [mailto:dmi...@zend.com]
> Sent: Monday, February 1, 2016 10:23 AM
> To: Anatol Belski ; internals@lists.php.net
> Cc: 'Pierre Joye' ; 'Xinchen Hui'
> ; 'Nikita Popov' 
> Subject: [PHP-DEV] Re: Streams and I/O refactoring approach
> 
> Hi,
> 
> At current state, I see this not as a whole stream layer refactoring, but
as a low-
> level replacement of POSIX layer on Windows.
> I see only few "visible" changes:
>
Basically it's the result of analyzing the code of particularly APR, libuv
and several other projects. While libuv works with UTF-8 paths only, APR
retains a wider compatibility. Please check the code here for an example

https://github.com/apache/apr/blob/trunk/file_io/win32/open.c#L321
 
> 1. The layer first checks, if file names are valid UTF-8 strings, and use
UTF-8
> names or fall back to system locale.
Yep, it is done for the fallback, and also the non-unicode part is
conditional, so can be turned off on compilation time with
PHP_WIN32_IOUTIL_ANSI_COMPAT_MODE set to 0. For an example how it is done in
APR

https://github.com/apache/apr/blob/trunk/file_io/win32/open.c#L406

Currently it would make sense to keep this fallback, so the current
scripts/codes using non-unicode would keep to work.

> 2. The patch allows to use long file names (longer than MAX_PATH) using
> "//?/**"
Yep, to do is to prepend \\?\ transparently for the user. But even without
\\?\ multibyte paths are supported.

> 3. Files now are opened in FILE_SHARE_READ | FILE_SHARE_WRITE |
> FILE_SHARE_DELETE mode (I'm not sure about intended better POSIX
> compliance and possible side effects).
> 
This is done in most projects, fe

https://github.com/apache/apr/blob/trunk/file_io/win32/open.c#L346

But we can remove it if there's something wrong.

> For me, the approach looks a bit inconsistent, especially the attempt to
use the
> same string as UTF-8 and then using some code page.
> 

The only difference of my approach to the other projects is that I suggest
to keep the POSIX compatible APIs, instead of having a whole scruct
describing a filesystem object, fe

https://ci.apache.org/projects/httpd/trunk/doxygen/structapr__file__t.html
 
It could be done later, but for now keeping POSIX APIs would be IMHO the
simplest solution. And as I've stated, it is just a preparation to have
everything at the same base, otherwise further improvements are quite
tedious.

Regards

Anatol





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

[PHP-DEV] Re: Streams and I/O refactoring approach

[Dmitry Stogov]

Hi,

At current state, I see this not as a whole stream layer refactoring, 
but as a low-level replacement of POSIX layer on Windows.

I see only few "visible" changes:

1. The layer first checks, if file names are valid UTF-8 strings, and 
use UTF-8 names or fall back to system locale.
2. The patch allows to use long file names (longer than MAX_PATH) using 
"//?/**"
3. Files now are opened in FILE_SHARE_READ | FILE_SHARE_WRITE | 
FILE_SHARE_DELETE mode (I'm not sure about intended better POSIX 
compliance and possible side effects).


For me, the approach looks a bit inconsistent, especially the attempt to 
use the same string as UTF-8 and then using some code page.


Thanks. Dmitry.


On 01/28/2016 05:48 PM, Anatol Belski wrote:

Hi,

I'm writing to ask for a review on the following:

https://gist.github.com/weltling/29779b61db26c62b5ab0

It is quite far from being even near to be ready. It is an approach for the
streams refactoring. After some time playing around, I think that the ideas
I was initially approaching are to the big part not applicable to our code
base in its current state. For one, "isolate the actual concrete low level
implementations by platforms" - it's probably the goal 1. that has to be
done before anything else. However creating an isolated layer of structs for
every platform (libuv alike) most likely is not doable at the current stage,
if at all (and whether makes sense).

So in this patch, I've started to create an I/O layer in win32, with the
goal to create a framework global to the whole PHP. This serves as the first
unavoidable step for the separation by platform. Ideally, we should have all
the abstracted low level I/O code for platforms concentrated at one place,
while currently all possible code parts of win32 I/O are spread over all the
code base - Zend, TSRM, ext/standard, win32.

In the current state it is hard to both maintain and to develop these pieces
of our codebase. So sounds like a gross refactoring which might last for
some longer time. For the Windows part it'll bring a huge functional
advantage of using the native win32 APIs which means support for multibyte
and long filepath and improved security, later probably overlapped I/O. For
the overall codebase it'll mean simpler and better readable code, so more
stability and possibility to extend with new modern features more easily.

Practically in this patch, with the approach I've described, I've
implemented several helpers and routines replacements for Windows that use
the native APIs. Particularly PHP's fopen and mkdir there support multibyte
filepaths and implementing the long path support is then quite easy. For
that to work cross platform, I define macros like php_ioutil_open,
php_ioutil_mkdir, etc. for the low level POSIX surrogates. There, I used
several parts from libuv to not to do everything from scratch. Also I've
started to pull the win32 related code out from zend_virtual_cwd.c, but
that's just a start. The plus of such approach is also that the work can be
done incrementally, moving the functions one by one, as the unported code
will stay compatible with function signatures and functionality.

Please let me know what you think about this approach as it's a very early
stage which would be good to take the corrections.

Thanks

Anatol

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

[François Laupretre]

Le 31/01/2016 23:14, Stanislav Malyshev a écrit :

Hi!


The only concern I have is that support of negative indexing will break
symmetry with (proper) arrays, where we cannot support negative indexing.


I think that was the main source of objections to this proposal in the
past. However, as one might say, string offsets are already not
symmetrical to array offsets - e.g. you can do $array["foo"] but not
$string["foo"].


However this is unlikely to be a significant issue. (I do however play with
the thought of reutilizing the obsolete {} indexing syntax to act as offset
indexing instead.)


I think it may be a good idea to start recommending using {} for string
offsets and [] for arrays. While both syntaxes may work for strings, the
intent (and expected handling of negatives, in this case) is much
clearer when different syntax is used.



Yes, authorizing array-related '[]' syntax on strings may look fine at 
first sight, but it only brings some unwanted ambiguity for no real 
benefit. And ambiguity increases with the support of negative string 
offsets.


So, I just added a chapter to the RFC, saying that documentation would 
be modified to recommend using the '{}' syntax for string offsets.


Regards

François

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

[PHP-DEV] Tutorials

[ty armour]

I am just looking for tutorials on developing a computer language. Every
part of developing a computer language.

I am also looking for tutorials on writing wrappers for php, like opengl,
alsa, jack, ladspa, gtk, wx,etcetera.

The more tutorials you post the more it will help development. If you
really get into it, you can write applications similar to guitarix lmms
hydrogen and rakarrack in php and have some fun with that.

you could even do the same thing with blender and it might be fun.

but yeah tutorials on writing a computer language and wrappers would be
beneficial and they would help development for you guys too.

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

[Nikita Popov]

On Sun, Jan 31, 2016 at 11:14 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > The only concern I have is that support of negative indexing will break
> > symmetry with (proper) arrays, where we cannot support negative indexing.
>
> I think that was the main source of objections to this proposal in the
> past. However, as one might say, string offsets are already not
> symmetrical to array offsets - e.g. you can do $array["foo"] but not
> $string["foo"].
>
> > However this is unlikely to be a significant issue. (I do however play
> with
> > the thought of reutilizing the obsolete {} indexing syntax to act as
> offset
> > indexing instead.)
>
> I think it may be a good idea to start recommending using {} for string
> offsets and [] for arrays. While both syntaxes may work for strings, the
> intent (and expected handling of negatives, in this case) is much
> clearer when different syntax is used.


I strongly disagree with this. $str[$offset] is well-recognized, generally
understood syntax that does not require familiarity with language
peculiarities. $str{$offset} might be clear to a Perl programmer, but to
anyone else this is just guesswork, with a typo being a reasonable
assumption.

We should be deprecating this alternative syntax instead of recommending
its use. I was under the impression that we *were* already discouraging its
use and it has already been temporarily deprecated.

Nikita

RE: [PHP-DEV] Re: Streams and I/O refactoring approach

[Anatol Belski]

Hi,

> -Original Message-
> From: Anatol Belski [mailto:anatol@belski.net]
> Sent: Monday, February 1, 2016 11:03 AM
> To: 'Dmitry Stogov' ; internals@lists.php.net
> Cc: 'Pierre Joye' ; 'Xinchen Hui'
> ; 'Nikita Popov' 
> Subject: RE: [PHP-DEV] Re: Streams and I/O refactoring approach
> 
> 
> Hi Dmitry,
> 
> Many thanks for the comments.
> 
> > -Original Message-
> > From: Dmitry Stogov [mailto:dmi...@zend.com]
> > Sent: Monday, February 1, 2016 10:23 AM
> > To: Anatol Belski ; internals@lists.php.net
> > Cc: 'Pierre Joye' ; 'Xinchen Hui'
> > ; 'Nikita Popov' 
> > Subject: [PHP-DEV] Re: Streams and I/O refactoring approach
> >
> > Hi,
> >
> > At current state, I see this not as a whole stream layer refactoring,
> > but
> as a low-
> > level replacement of POSIX layer on Windows.
> > I see only few "visible" changes:
> >
> Basically it's the result of analyzing the code of particularly APR, libuv
and
> several other projects. While libuv works with UTF-8 paths only, APR
retains a
> wider compatibility. Please check the code here for an example
> 
> https://github.com/apache/apr/blob/trunk/file_io/win32/open.c#L321
> 
> > 1. The layer first checks, if file names are valid UTF-8 strings, and
> > use
> UTF-8
> > names or fall back to system locale.
> Yep, it is done for the fallback, and also the non-unicode part is
conditional, so
> can be turned off on compilation time with
> PHP_WIN32_IOUTIL_ANSI_COMPAT_MODE set to 0. For an example how it is
> done in APR
> 
> https://github.com/apache/apr/blob/trunk/file_io/win32/open.c#L406
> 
> Currently it would make sense to keep this fallback, so the current
scripts/codes
> using non-unicode would keep to work.
> 
> > 2. The patch allows to use long file names (longer than MAX_PATH)
> > using "//?/**"
> Yep, to do is to prepend \\?\ transparently for the user. But even without
\\?\
> multibyte paths are supported.
> 
> > 3. Files now are opened in FILE_SHARE_READ | FILE_SHARE_WRITE |
> > FILE_SHARE_DELETE mode (I'm not sure about intended better POSIX
> > compliance and possible side effects).
> >
> This is done in most projects, fe
> 
> https://github.com/apache/apr/blob/trunk/file_io/win32/open.c#L346
> 
> But we can remove it if there's something wrong.
> 
> > For me, the approach looks a bit inconsistent, especially the attempt
> > to
> use the
> > same string as UTF-8 and then using some code page.
> >
> 
> The only difference of my approach to the other projects is that I suggest
to
> keep the POSIX compatible APIs, instead of having a whole scruct
describing a
> filesystem object, fe
> 
> https://ci.apache.org/projects/httpd/trunk/doxygen/structapr__file__t.html
> 
> It could be done later, but for now keeping POSIX APIs would be IMHO the
> simplest solution. And as I've stated, it is just a preparation to have
everything at
> the same base, otherwise further improvements are quite tedious.
> 
After some discussions and rethinking this approach, I came to conclusion
that creating a layer with POSIX compatible signatures for low level IO is
most likely not a good idea. I won't continue on this idea and rather going
for an RFC to target better APIs and refactoring for the low level IO layer.
Though probably it were worth to reuse the parts of this patch to add the
missing features in the current code base.

Thanks.

Anatol


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

[PHP-DEV] GOOD Benchmark Results for PHP Master 2016-02-01

[lp_benchmark_robot]

Results for project PHP master, build date 2016-02-01 06:29:53+02:00
commit: 678300a
previous commit:1b36037
revision date:  2016-01-31 18:14:37+00:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.10%  0.04%  0.31%  
  7.44%
:-|   Drupal 7.36 cgi -T1  0.14%  0.12% -0.02%  
  4.60%
:-)   MediaWiki 1.23.9 cgi -T5000  0.11%  1.14%  1.47%  
  3.11%
:-|   bench.php cgi -T100  0.01% -0.09%  0.20%  
  6.59%
:-|  micro_bench.php cgi -T10  0.02% -0.15%  0.30%  
  4.32%
:-|  mandelbrot.php cgi -T100  0.01%  0.01%-13.11%  
  0.15%
---
* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/good-benchmark-results-for-php-master-2016-02-01/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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