[PHP-DEV] BAD Benchmark Results for PHP Master 2017-05-31

[lp_benchmark_robot]

Results for project PHP master, build date 2017-05-31 19:23:44-07:00
commit: d1cfd87
previous commit:32200e0
revision date:  2017-05-31 14:23:57-07: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.23%  0.36%  2.57%  
  8.15%
:-|   Drupal 7.36 cgi -T1  0.22%  0.07%  0.07%  
  5.21%
:-|   MediaWiki 1.23.9 cgi -T5000  0.11%  0.15%  2.58%  
  3.90%
:-(   bench.php cgi -T100  0.01% -1.37% 45.90%  
  4.23%
:-(  micro_bench.php cgi -T10  0.00% -3.02% 18.89%  
  6.19%
:-(  mandelbrot.php cgi -T100  0.02% -1.01% 43.96%  
  4.05%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2017-05-31/

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

[PHP-DEV] [RFC] [Discussion] Doxygen

[Fleshgrinder]

Hey guys!

Just finished the very brief Doxygen RFC. Please let me know if you
require more information in it, I feel that it is sufficient as is,
since documenting is not rocket science (writing useful documentation
definitely is, but we cannot vote on that):

https://wiki.php.net/rfc/doxygen

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Theodore Brown]

On Tuesday, May 30, 2017 at 12:58 PM, Levi Morrison wrote:

> Based on the discussion there are a few different syntax choices
> people liked. Overall it's a feature that people seem to want but
> everyone seems to prefer a different syntax choice.
>
> 1. fn(params) => expr
> 2. function(params) => expr
> 3. (params) ==> expr
> 4. (params) => expr
> 5.
> [](params) => expr // binds no values
> [=](params) => expr // binds by value
> [&](params) => expr // binds by reference

As a userland developer, I've been waiting/hoping for short arrow
functions for a long time!

Option 3 seems like the most obvious choice, since that's the
same syntax Hack uses. Would it be very difficult to implement the
parser changes necessary for this syntax? Or is there some other
downside to a more powerful grammar/parser (e.g. worse performance)?

If option 3 isn't viable, my next preference would be option 1.
Presumably the drawback of a new symbol is that it might break
existing code using `fn` as the name of a class or function.
However, using a new symbol would arguably enable more readable
code than the other options.

Option 2 is not only lengthy, but it also could be confusing
since it reuses the `function` symbol for something that isn't
a normal function.

Option 5 seems overly complex and hard to read.

Whether option 1, 2, or 3 is used, to me it seems that capturing by
reference would be the most useful and intuitive behavior. It's
intuitive since implicit capture makes it feel like all the captured
variables are in the same scope.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC][VOTE] Allow loading extensions by name

[François Laupretre]

Sorry, forgot [VOTE] in subject...

Le 01/06/2017 à 14:46, François Laupretre a écrit :

Hi,

Feature was discussed last year. I am now opening the vote for a merge 
in 7.2.


URL: https://wiki.php.net/rfc/load-ext-by-name

Voting period ends Monday, June 19, 2017, 00:00 UTC.

Regards

François




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

Re: [PHP-DEV] Class Naming in Core

[Rowan Collins]

On 1 June 2017 10:16:16 BST, Tony Marston  wrote:
>"Rowan Collins"  wrote in message 
>news:cef783bb-8e1f-4a20-9cc6-1364a122b...@gmail.com...
>>
>>On 31 May 2017 10:26:06 BST, Tony Marston 
>wrote:
>>>wrote in message
>>>news:86dba466-a764-522b-6990-39fd7668a...@fleshgrinder.com...
>>>I should point out that snake_case was the universal standard decades
>>>before some people switched to CamelCase.
>>
>>[citation needed]
>
>My first job in computing was with a UNIVAC 1108 mainframe in the
>1970s. 
>This used a 6-bit character instead of an 8-bit byte, which meant that
>it 
>could support upper case characters, but not lower case. Where a name
>was 
>comprised of several words an underscore separator was used, as in 
>"end_of_file".

Fascinating, but doesn't make it "universal", or frankly have anything to do 
with how we write code 40 years later.


>>> That was only because some software could
>>>not handle long names, but could handle both upper and lower case, so
>>>an upper case character was used instead of an underscore.
>>
>>[citation needed]
>
>Try reading 
>https://en.wikipedia.org/wiki/Naming_convention_(programming)#Length_of_identifiers

Mentions absolutely nothing about the origins of CamelCase, which a quick 
search suggests is somewhat unknown. One theory is apparently environments 
whose character sets had replaced underscore with a left-arrow assignment 
operator. Which, again, is fascinating but is as irrelevant to designing modern 
languages as the origins of the word "beef" is to ordering a cheeseburger.


>Some studies have shown that that most people find it easier to read 
>compound names which use the underscore separator. Look at the
>following:
>
>https://en.wikipedia.org/wiki/Camel_case#Readability_studies
>https://en.wikipedia.org/wiki/Snake_case  (first paragraph)


This, however, is at least tangentially relevant to the original topic, since 
it shows some reasons to pick one convention over the other.

Even more relevant would be studies testing the advantages of having a 
convention at all, which I would expect to include increased efficiency and 
reduced mistakes because it's easier to remember a list of items that follow a 
fixed pattern.

Regards,

-- 
Rowan Collins
[IMSoP]

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

[PHP-DEV] [RFC] Allow loading extensions by name

[François Laupretre]

Hi,

Feature was discussed last year. I am now opening the vote for a merge 
in 7.2.


URL: https://wiki.php.net/rfc/load-ext-by-name

Voting period ends Monday, June 19, 2017, 00:00 UTC.

Regards

François


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

Re: [PHP-DEV] Class Naming in Core

[Tony Marston]

"Rowan Collins"  wrote in message 
news:cef783bb-8e1f-4a20-9cc6-1364a122b...@gmail.com...


On 31 May 2017 10:26:06 BST, Tony Marston  wrote:

wrote in message
news:86dba466-a764-522b-6990-39fd7668a...@fleshgrinder.com...
I should point out that snake_case was the universal standard decades
before some people switched to CamelCase.


[citation needed]


My first job in computing was with a UNIVAC 1108 mainframe in the 1970s. 
This used a 6-bit character instead of an 8-bit byte, which meant that it 
could support upper case characters, but not lower case. Where a name was 
comprised of several words an underscore separator was used, as in 
"end_of_file".


Lisp, for instance, uses hyphens to separate words, and has don't since the 
1950s.



That was only because some software could
not handle long names, but could handle both upper and lower case, so
an upper case character was used instead of an underscore.


[citation needed]


Try reading 
https://en.wikipedia.org/wiki/Naming_convention_(programming)#Length_of_identifiers


I'm sorry, but this smells of folklore and guesswork to me. Both 
underscores and mixed case are workarounds for the inability to include 
spaces in identifiers, and have their pros and cons, most of which these 
days come down to opinions on aesthetics.


Some studies have shown that that most people find it easier to read 
compound names which use the underscore separator. Look at the following:


https://en.wikipedia.org/wiki/Camel_case#Readability_studies
https://en.wikipedia.org/wiki/Snake_case  (first paragraph)

This is not guesswork on my part, it is a documented fact.

--
Tony Marston


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