[PHP-DEV] Re: Object getter method optimization

[Lin Yo-An]

On Tue, Apr 5, 2016 at 10:14 PM, Dmitry Stogov  wrote:

> I think, op_array->type and op_array->fn_flags can't be reused.
>
> Also, usage of op_array->run_time_cache is safer (I remember, I saw some
> SIGSEGV with your patch and opcache.protect_memory=1)
>
Got it.Does run_time_cache vary when caller is different? maybe I can
use the first 2 bytes for the accessor information.

Cheers, Yo-An

[PHP-DEV] Re: Object getter method optimization

[Lin Yo-An]

I updated my PR here
https://github.com/php/php-src/pull/1847/files#diff-3054389ad750ce9a9f5895cd6d27800fR3159


On Tue, Apr 5, 2016 at 10:02 PM, Lin Yo-An  wrote:

> sorry, one typo, the "op_array->type" should be "op_array->fn_flags"
>



-- 
Best Regards,

Yo-An Lin

[PHP-DEV] Re: Object getter method optimization

[Lin Yo-An]

sorry, one typo, the "op_array->type" should be "op_array->fn_flags"

[PHP-DEV] Re: Object getter method optimization

[Dmitry Stogov]

I think, op_array->type and op_array->fn_flags can't be reused.

Also, usage of op_array->run_time_cache is safer (I remember, I saw some 
SIGSEGV with your patch and opcache.protect_memory=1)


Most probably, I'll able to return to this idea only at the end of the week or 
even on next week.


Thanks. Dmitry.



From: Lin Yo-An 
Sent: Tuesday, April 5, 2016 17:00
To: Dmitry Stogov
Cc: Xinchen Hui; Nikita Popov; Bob Weinand; Joe Watkins; internals
Subject: Re: Object getter method optimization

Hi Dmitry,


Glad to hear your news, I just checked your patch and I like the approach 
you've done. :]

I'm also still working on this idea this week, the const value accessor support 
was just added today.  And I guess we may also support setters in the future 
(if possible)

my thought is:

- I think the getter optimization is useful since getter methods are heavily 
used in a lot of application like Drupal (like hundreds)

- If we could produce more information in compile-time, we can reduce more 
runtime cost when executing the opcode handler. This way, we can reduce the 
impact to the overall performance.

- I found the first two bytes in zend_op_array produces a 2 bytes room on 32bit 
machine and even more on 64bit machine because the memory alignment (not sure 
if it could be optimzed when memory alignment optimization is not enabled with 
gcc)


My first attempt was to add a new flag in op_array->type, however it's already 
full, all bits are used currently.

I think we can either extend the op_array type to uint32 or just add a new 
zend_uchar field to save the information (from the 2 bytes room). And using 
cache slot to save the property offset information.

This field will be not only for simple getters, but also for simple setters and 
functions return const or return values that are simplified to scalar value.

Your thoughts?



Cheers, Yo-An









On Tue, Apr 5, 2016 at 7:29 PM, Dmitry Stogov 
> wrote:

Hi Yo-An Lin,


I spent few hours working on your idea and came to the following path.


https://gist.github.com/dstogov/2221ffc21ac16311c958a4830dbcee0f


I tried to keep binary compatibility, minimize run-time checks overhead and fix 
related problems and leaks.

BTW I'm not sure, if I like the patch even in this state.


The patch significantly speed-ups getters (more than 2 times) in small cost for 
all other methods, but the final effect on application may be negative.

Of course, we may add specialized opcode for INIT_METHOD_CALL without 
arguments, that would almost completely eliminate overhead.


Anyway, I like to listen opinions:

- if we should include such optimizations?

- do you see any other applications to similar optimizations?


Thanks. Dmitry.



From: Lin Yo-An >
Sent: Sunday, April 3, 2016 11:10
To: Xinchen Hui
Cc: Dmitry Stogov; internals; Nikita Popov
Subject: Re: Object getter method optimization

I submitted the new benchmark result here:

Benchmark Result
Getter Method Only

https://gist.github.com/8cd230a5601cbe38439661adf3caca0d

Without getter optimization (3 runs):
151.0169506073ms

With getter optimization (3 runs)
39.201021194458ms

Template Engine Benchmark

https://gist.github.com/a23cf294dfcf74683b8f02d93a47bc5b

With getter optimization:
1118ms

Without getter optimization:
1235ms

Affect

Other Microbench result: 
https://gist.github.com/c9s/0273ac21631562724cabf86c42e86e32

On Sat, Apr 2, 2016 at 11:29 AM, Lin Yo-An 
> wrote:
Hi Xinchen Hui,

The magic get method is not being optimized. This optimization only focuses on 
simple getter, which is used in a lot of OO-based appoications like Symfony or 
Drupal.


Hi Dimitry,

Thanks for reviewing the code, comments are helpful. :) could you explain a 
little bit of how runtime_cache_slot works?

 I think adding the property_offset in op_array is kinda like a workaround for 
POC, and I want to remove it from op_array.


Cheers, Yo-An


Xinchen Hui > 於 2016年4月1日 星期五寫道：

Hey:

On Fri, Apr 1, 2016 at 4:35 PM, Lin Yo-An  wrote:
Hi Dmitry, Nikita, Andrea


My implementation now is able to get the property offset and fetch object 
property directly without invoking zend_std_read_property and pushing new call 
frame onto the stack.

The current behavior:

1. In compile-time, the pass_two() function now marks the getter functions in 
op_array.accessor.type

2. When Zend Engine first time attempt to read the property, it saves the 
property offset in the accessor field and mark the method as a "getter".
I am not sure if I understand you correctly, but.. have you consider this case?

a;
} else {
return $this->b;
}
}
}


$a = new A();
echo $a->nomeaning;
echo $a->nomeaning;
?>

thanks

[PHP-DEV] Re: Object getter method optimization

[Lin Yo-An]

Hi Dmitry,


Glad to hear your news, I just checked your patch and I like the approach
you've done. :]

I'm also still working on this idea this week, the const value accessor
support was just added today.  And I guess we may also support setters in
the future (if possible)

my thought is:

- I think the getter optimization is useful since getter methods are
heavily used in a lot of application like Drupal (like hundreds)

- If we could produce more information in compile-time, we can reduce more
runtime cost when executing the opcode handler. This way, we can reduce the
impact to the overall performance.

- I found the first two bytes in zend_op_array produces a 2 bytes room on
32bit machine and even more on 64bit machine because the memory alignment
(not sure if it could be optimzed when memory alignment optimization is not
enabled with gcc)


My first attempt was to add a new flag in op_array->type, however it's
already full, all bits are used currently.

I think we can either extend the op_array type to uint32 or just add a new
zend_uchar field to save the information (from the 2 bytes room). And using
cache slot to save the property offset information.

This field will be not only for simple getters, but also for simple setters
and functions return const or return values that are simplified to scalar
value.

Your thoughts?



Cheers, Yo-An









On Tue, Apr 5, 2016 at 7:29 PM, Dmitry Stogov  wrote:

> Hi Yo-An Lin,
>
>
> I spent few hours working on your idea and came to the following path.
>
>
> https://gist.github.com/dstogov/2221ffc21ac16311c958a4830dbcee0f
>
>
> I tried to keep binary compatibility, minimize run-time checks overhead
> and fix related problems and leaks.
>
> BTW I'm not sure, if I like the patch even in this state.
>
>
> The patch significantly speed-ups getters (more than 2 times) in small
> cost for all other methods, but the final effect on application may be
> negative.
>
> Of course, we may add specialized opcode for INIT_METHOD_CALL without
> arguments, that would almost completely eliminate overhead.
>
>
> Anyway, I like to listen opinions:
>
> - if we should include such optimizations?
>
> - do you see any other applications to similar optimizations?
>
>
> Thanks. Dmitry.
>
>
> --
> *From:* Lin Yo-An 
> *Sent:* Sunday, April 3, 2016 11:10
> *To:* Xinchen Hui
> *Cc:* Dmitry Stogov; internals; Nikita Popov
> *Subject:* Re: Object getter method optimization
>
> I submitted the new benchmark result here:
>
> Benchmark Result Getter Method Only
>
> https://gist.github.com/8cd230a5601cbe38439661adf3caca0d
>
> Without getter optimization (3 runs):
> 151.0169506073ms
>
> With getter optimization (3 runs)
> 39.201021194458ms
> Template Engine Benchmark
>
> https://gist.github.com/a23cf294dfcf74683b8f02d93a47bc5b
>
> With getter optimization:
> 1118ms
>
> Without getter optimization:
> 1235ms
> Affect
>
> Other Microbench result:
> https://gist.github.com/c9s/0273ac21631562724cabf86c42e86e32
>
> On Sat, Apr 2, 2016 at 11:29 AM, Lin Yo-An 
> wrote:
>
>> Hi Xinchen Hui,
>>
>> The magic get method is not being optimized. This optimization only
>> focuses on simple getter, which is used in a lot of OO-based appoications
>> like Symfony or Drupal.
>>
>>
>> Hi Dimitry,
>>
>> Thanks for reviewing the code, comments are helpful. :) could you explain
>> a little bit of how runtime_cache_slot works?
>>
>>  I think adding the property_offset in op_array is kinda like a
>> workaround for POC, and I want to remove it from op_array.
>>
>>
>> Cheers, Yo-An
>>
>>
>> Xinchen Hui  於 2016年4月1日 星期五寫道：
>>
>> Hey:
>>>
>>> On Fri, Apr 1, 2016 at 4:35 PM, Lin Yo-An 
>>> wrote:
>>>
 Hi Dmitry, Nikita, Andrea


 My implementation now is able to get the property offset and fetch
 object property directly without invoking zend_std_read_property and
 pushing new call frame onto the stack.

 The current behavior:

 1. In compile-time, the pass_two() function now marks the getter
 functions in op_array.accessor.type

 2. When Zend Engine first time attempt to read the property, it saves
 the property offset in the accessor field and mark the method as a 
 "getter".

>>> I am not sure if I understand you correctly, but.. have you consider
>>> this case?
>>>
>>> >> class A {
>>> private $a = 1;
>>> private $b = 2;
>>> public function __get($name) {
>>> static $is_first = 1;
>>> if ($is_first) {
>>> $is_first = 0;
>>> return $this->a;
>>> } else {
>>> return $this->b;
>>> }
>>> }
>>> }
>>>
>>>
>>> $a = new A();
>>> echo $a->nomeaning;
>>> echo $a->nomeaning;
>>> ?>
>>>
>>> thanks
>>>

 3. When Zend Engine second time invoke the getter method, it checks the
 accessor field and try to read the property value directly 

Re: [PHP-DEV] RETURN micro optimization

[Joe Watkins]

Dmitry,

No worries ... I had just found out it wasn't particular to phpdbg ...



Cheers
Joe

On Tue, Apr 5, 2016 at 1:14 PM, Dmitry Stogov  wrote:

>
>
> On 04/05/2016 12:04 PM, Derick Rethans wrote:
>
>> On Tue, 5 Apr 2016, Dmitry Stogov wrote:
>>
>> I propose a micro optimization for RETURN statement.
>>>
>>> Currently "return $x" increments reference counter of $x, then in
>>> zend_leave_helper() we perform zval_ptr_dtor() on the same $x.
>>>
>>> The patch sets the original value of $x to null in first place, so
>>> zval_ptr_dtor() is not going to be called.
>>>
>>> https://gist.github.com/dstogov/36f68b206242a39691ac539c2fc85d40
>>>
>>> the performance impact is invisible (0.1% less instruction retired on
>>> Wordpress).
>>>
>>> It breaks sapi/phpdbg/tests/breakpoints_005.phpt, but this is probably
>>> not a big deal.
>>>
>>> BTW: this change may affect debuggers in some other way.
>>>
>> I'd like to know why this breaks before saying something. It'd be a PITA
>> if this micro optimisation wouldn't actually do a lot performance wise,
>> but makes some debugging not possible.
>>
> Actually, the patch has a bug.
> It doesn't take into account that "return $x;" might be used in global
> scope.
> Setting $x to NULL in this case isn't right, of course.
>
> Introducing another check would probably negate the effect of
> micro-optimization.
>
> So, ignore this for now, and sorry for noise.
>
> Thanks. Dmitry.
>
>
>
>
>> cheers,
>> Derick
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RETURN micro optimization

[Dmitry Stogov]

On 04/05/2016 12:04 PM, Derick Rethans wrote:

On Tue, 5 Apr 2016, Dmitry Stogov wrote:


I propose a micro optimization for RETURN statement.

Currently "return $x" increments reference counter of $x, then in
zend_leave_helper() we perform zval_ptr_dtor() on the same $x.

The patch sets the original value of $x to null in first place, so
zval_ptr_dtor() is not going to be called.

https://gist.github.com/dstogov/36f68b206242a39691ac539c2fc85d40

the performance impact is invisible (0.1% less instruction retired on
Wordpress).

It breaks sapi/phpdbg/tests/breakpoints_005.phpt, but this is probably
not a big deal.

BTW: this change may affect debuggers in some other way.

I'd like to know why this breaks before saying something. It'd be a PITA
if this micro optimisation wouldn't actually do a lot performance wise,
but makes some debugging not possible.

Actually, the patch has a bug.
It doesn't take into account that "return $x;" might be used in global 
scope.

Setting $x to NULL in this case isn't right, of course.

Introducing another check would probably negate the effect of 
micro-optimization.


So, ignore this for now, and sorry for noise.

Thanks. Dmitry.




cheers,
Derick



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

Re: [PHP-DEV] Copy On Write and Assign By Reference perform different on PHP5 and PHP7

[Rowan Collins]

Sara Golemon wrote on 01/04/2016 02:52:

On Thu, Mar 31, 2016 at 9:47 AM, Huqiu Liao  wrote:

I have a question about Assign By Reference and I posted on StackOverflow,
I'd like to know the reason behind it, and I did not get any this kind of
answer, can anyone give me some clues.


Are you asking out of curiosity? Or because you think a new bug has
been introduced in PHP7?

If the latter, I'd respond by pointing out that the behavior of using
multiple operations with side-effects (like pre/post inc/dec) is
defined as undefined.  That is, while the PHP reference implementation
may give you a particular result, you should not rely on that result.




I just dug into the spec out of curiosity, and I have a nit-pick: there 
is relevant language under "Section 10: Expressions" [1]:


> Unless stated explicitly in this specification, the order in which 
the operands in an expression are evaluated relative to each other is 
unspecified. [...] (For example,[...] in the full expression $j = $i + 
$i++, whether the value of $i is the old or new $i, is unspecified.)


But arguably this doesn't go far enough to justify the PHP 5 engine's 
behaviour in this case, because it only mentions the *order* of 
evaluation being unspecified, not the actual semantics. The definition 
of the pre-increment operator [2] states:


> The result is the value of the operand after it has been incremented.

That is, the operator does not return the operand itself, but its value 
at a particular time. However, there is no order of execution which 
allows the value of the variable to be 4 on both sides of the addition; 
to get this requires the actual behaviour of the ++ operator to be 
re-defined as "return a reference to the incremented operand". (You 
could make an argument for the two increments happening "simultaneously" 
and giving a result of 6, but to get 8, they have to both happen 
simultaneously *and* see each other's results.)


I'm not seriously suggesting that the PHP 5 behaviour is problematic, 
but unless there are additional caveats somewhere else, it does seem to 
violate the letter of the current spec.


[1] https://github.com/php/php-langspec/blob/master/spec/10-expressions.md
[2] 
https://github.com/php/php-langspec/blob/master/spec/10-expressions.md#prefix-increment-and-decrement-operators


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] RETURN micro optimization

[Dmitry Stogov]

But somehow it broke one phpdbg test, so it's better to check.

Thanks. Dmitry.

On 04/05/2016 12:15 PM, Joe Watkins wrote:

Morning Derick,

I don't think it does make anything impossible, it's just a more 
efficient copying method in the EXPECTED branch is all.


Cheers
Joe

On Tue, Apr 5, 2016 at 10:04 AM, Derick Rethans > wrote:


On Tue, 5 Apr 2016, Dmitry Stogov wrote:

> I propose a micro optimization for RETURN statement.
>
> Currently "return $x" increments reference counter of $x, then in
> zend_leave_helper() we perform zval_ptr_dtor() on the same $x.
>
> The patch sets the original value of $x to null in first place, so
> zval_ptr_dtor() is not going to be called.
>
> https://gist.github.com/dstogov/36f68b206242a39691ac539c2fc85d40
>
> the performance impact is invisible (0.1% less instruction
retired on
> Wordpress).
>
> It breaks sapi/phpdbg/tests/breakpoints_005.phpt, but this is
probably
> not a big deal.
>
> BTW: this change may affect debuggers in some other way.

I'd like to know why this breaks before saying something. It'd be
a PITA
if this micro optimisation wouldn't actually do a lot performance
wise,
but makes some debugging not possible.

cheers,
Derick

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

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-04-05

[lp_benchmark_robot]

Results for project PHP master, build date 2016-04-05 06:34:55+03:00
commit: b68e89e
previous commit:e7730fe
revision date:  2016-04-05 00:07:28+02: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.24%  0.04%  0.75%  
  6.81%
:-|   Drupal 7.36 cgi -T1  0.13%  0.11% -0.20%  
  4.02%
:-|   MediaWiki 1.23.9 cgi -T5000  0.07%  0.22%  1.50%  
  3.52%
:-|   bench.php cgi -T100  0.42%  0.33% 23.20%  
  1.62%
:-|  micro_bench.php cgi -T10  0.02%  0.09%  6.23%  
  3.65%
:-(  mandelbrot.php cgi -T100  0.10% -1.22% 28.64%  
  8.62%
---
* 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-2016-04-05/

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] Re: Object getter method optimization

[Dmitry Stogov]

Hi Yo-An Lin,


I spent few hours working on your idea and came to the following path.


https://gist.github.com/dstogov/2221ffc21ac16311c958a4830dbcee0f


I tried to keep binary compatibility, minimize run-time checks overhead and fix 
related problems and leaks.

BTW I'm not sure, if I like the patch even in this state.


The patch significantly speed-ups getters (more than 2 times) in small cost for 
all other methods, but the final effect on application may be negative.

Of course, we may add specialized opcode for INIT_METHOD_CALL without 
arguments, that would almost completely eliminate overhead.


Anyway, I like to listen opinions:

- if we should include such optimizations?

- do you see any other applications to similar optimizations?


Thanks. Dmitry.



From: Lin Yo-An 
Sent: Sunday, April 3, 2016 11:10
To: Xinchen Hui
Cc: Dmitry Stogov; internals; Nikita Popov
Subject: Re: Object getter method optimization

I submitted the new benchmark result here:

Benchmark Result
Getter Method Only

https://gist.github.com/8cd230a5601cbe38439661adf3caca0d

Without getter optimization (3 runs):
151.0169506073ms

With getter optimization (3 runs)
39.201021194458ms

Template Engine Benchmark

https://gist.github.com/a23cf294dfcf74683b8f02d93a47bc5b

With getter optimization:
1118ms

Without getter optimization:
1235ms

Affect

Other Microbench result: 
https://gist.github.com/c9s/0273ac21631562724cabf86c42e86e32

On Sat, Apr 2, 2016 at 11:29 AM, Lin Yo-An 
> wrote:
Hi Xinchen Hui,

The magic get method is not being optimized. This optimization only focuses on 
simple getter, which is used in a lot of OO-based appoications like Symfony or 
Drupal.


Hi Dimitry,

Thanks for reviewing the code, comments are helpful. :) could you explain a 
little bit of how runtime_cache_slot works?

 I think adding the property_offset in op_array is kinda like a workaround for 
POC, and I want to remove it from op_array.


Cheers, Yo-An


Xinchen Hui > 於 2016年4月1日 星期五寫道：

Hey:

On Fri, Apr 1, 2016 at 4:35 PM, Lin Yo-An  wrote:
Hi Dmitry, Nikita, Andrea


My implementation now is able to get the property offset and fetch object 
property directly without invoking zend_std_read_property and pushing new call 
frame onto the stack.

The current behavior:

1. In compile-time, the pass_two() function now marks the getter functions in 
op_array.accessor.type

2. When Zend Engine first time attempt to read the property, it saves the 
property offset in the accessor field and mark the method as a "getter".
I am not sure if I understand you correctly, but.. have you consider this case?

a;
} else {
return $this->b;
}
}
}


$a = new A();
echo $a->nomeaning;
echo $a->nomeaning;
?>

thanks

3. When Zend Engine second time invoke the getter method, it checks the 
accessor field and try to read the property value directly instead a "method 
call"



The implementation did some change:

1. Added accessor struct to op_array to save "accessor" related information 
(getter or setter, property offset)

2. Added two statement in zend_std_read_property to save property offset.

3. Added op code check in zend_compile (The pass_two() function) to mark a 
function is a getter)


But now I encountered a problem, I can't store the result value in 
INIT_METHOD_CALL op, the result var is only available in DO_FCALL_*



I have an idea for solving this, but I'm not sure if it's good or not:


If DO_FCALL_* will always follow a INIT_METHOD_CALL, then I think we can store 
result var from the next op (DO_FCALL) and skip DO_FCALL directly.


Would be great if I can have your advices and suggestion. :-)


Thanks, Yo-An Lin


















On Tue, Mar 22, 2016 at 4:45 PM, Dmitry Stogov  wrote:

Hi Yo-An Lin,


This "run-time inlining" approach may work.


PHP compiler (or optimizer) may mark functions and methods suitable for 
"run-time" inlining (e.g. methods without arguments and FETCH_OBJ_R UNUSED, 
CONST -> TMP; RETURN TMP).

Then INIT_METHOD_CALL may check this flag and execute "optimized code sequence" 
instead of pushing stack frame and real call.


However, I'm not sure what kind of performance impact this may make, because we 
will have to make additional check on each INIT_METHOD_CALL execution.


Thanks. Dmitry.



From: Lin Yo-An 
Sent: Saturday, March 19, 2016 10:08
To: Dmitry Stogov
Cc: internals; Xinchen Hui
Subject: Re: [PHP-DEV] Object getter method optimization

Hi Dmitry,


Thanks for your reply! You're correct. let me try to explain your points:

If I have a main.php and worker.php

And I defined work($worker) { $status = $worker->getStatus(); } inside main.php

when main.php is compiled, we don't know what the class entry of $worker is. 
What we only 

Re: [PHP-DEV] Final properties

[Michał Brzuchalski]

Hi,

2016-04-05 12:13 GMT+02:00 Marco Pivetta :

> Hi,
>
> On 5 April 2016 at 12:06, Michał Brzuchalski 
> wrote:
>
>> Hi Marco,
>>
>> Ad. 1 it is posiible to redeclare in a sub-class final property as
>> non-final, here is some gist presenting my current impl working like:
>> https://gist.github.com/brzuchal/12ebda1efed59440a78ba43bff116728
>>
>
>
It works with public, private and protected properties.


> Does this work for public properties as well?
>
>
>> Ad. 2. `final` means class variable (like static) or class instance
>> property can not change their reference, it is impossible to replace zval
>> in such property, in my opinion `immutable` is object behavior when using
>> some methods you receive newly created (cloned) object which is changed
>> exactly like `DateTimeImmutable`
>> http://php.net/manual/en/datetimeimmutable.add.php
>>
>
> I am aware of what `final` means in other languages, it just seems that
> everyone then needs to translate back and forth from `final` to
> `immutable`. In addition to that, `final` has different meaning in
> inheritance (re-used keyword), so this adds to the confusion for people
> unfamiliar with the feature.
>
> Wiki about Final in Java
https://www.wikiwand.com/en/Final_(Java)#/Final_variables says:

# Final variables
A final variable can only be initialized once, either via an initializer or
an assignment statement. It does not need to be initialized at the point of
declaration: this is called a "blank final" variable. A blank final
instance variable of a class must be definitely assigned in every
constructor of the class in which it is declared; similarly, a blank final
static variable must be definitely assigned in a static initializer of the
class in which it is declared; otherwise, a compile-time error occurs in
both cases.[6] (Note: If the variable is a reference, this means that the
variable cannot be re-bound to reference another object. But the object
that it references is still mutable, if it was originally mutable.)

I took the name from Java and only implemented behavior like that, thats wy
I used `final`.


>> Ad. 3 it would be awesome if there could be final variables in general,
>> it would be quite stable if no one could change your variable, AFAIK zvals
>> have IMMUTABLE flag which could be used, don't know it for sure I'm rather
>> PHP dev than C there would be need some internals guru to ask if it's
>> posiible.
>>
>> P.S. We've meet on PHPCon'15 in Poland, thanks for +1.
>>
>
> YW!
>
>
>>
>> Cheers,
>> --
>> Michał Brzuchalski (aka brzuchal)
>>
>> 2016-04-05 11:13 GMT+02:00 Marco Pivetta :
>>
>>> Hi Michał,
>>>
>>> First of all: +1 to this: very useful for value objects!
>>>
>>> A few questions:
>>>
>>>  * can you re-declare a final property in a sub-class, making it
>>> therefore non-final? (I have reasons to do that, related with altering
>>> states via mappers)
>>>  * do we want to use `final`, or `immutable` for these properties?
>>> `final` seems to just be a confusing term here.
>>>  * is this feature portable to variables in general? I realize that
>>> adding metadata to ZVals has huge performance implications, but it would be
>>> interesting to do that for performance improvements further down the line
>>>
>>> Cheers,
>>>
>>>
>>> Marco Pivetta
>>>
>>> http://twitter.com/Ocramius
>>>
>>> http://ocramius.github.com/
>>>
>>> On 4 April 2016 at 19:53, Michał Brzuchalski 
>>> wrote:
>>>
 Hey Internals,

 I'm new here. I've been wondering / working on adding final properties
 into
 PHP lang.

 This work started once I had the time to read the "Core Java for
 Impateient" by Cay S. Horstmann
 and found it very usefull to have final properties like Java.

 Those properties differ than `const` because they can be set at runtime
 -
 but only once in their lifetime.
 Such properties could be very usefull in Singletons, ValueObjects etc.
 impl
 like:

 class Money {
 public final $amount;
 public final $currency;
 public function __constructor($amount, $currency) {
 $this->amount = $amount;
 $this->currency = $currency;
 }
 }

 In above example there is even no need for getter because those
 properties
 are immutable through
 the final keyword, it means those properties cannot change their
 references
 just like in Java
 https://en.wikipedia.org/wiki/Final_(Java)

 I've already started some impl on own fork

 https://github.com/php/php-src/compare/master...brzuchal:final-properties
 I've got some basics in C programming, don't know yet if I can impl it
 complex.

 I was wondering if it is usefull in yours opinion or is it only my
 impression.

 I can provide an RFC if it sounds usefull and if I get Wiki karma

 Thanks
 --
 Michał Brzuchalski 

Re: [PHP-DEV] Final properties

[Marco Pivetta]

Hi,

On 5 April 2016 at 12:06, Michał Brzuchalski  wrote:

> Hi Marco,
>
> Ad. 1 it is posiible to redeclare in a sub-class final property as
> non-final, here is some gist presenting my current impl working like:
> https://gist.github.com/brzuchal/12ebda1efed59440a78ba43bff116728
>

Does this work for public properties as well?


> Ad. 2. `final` means class variable (like static) or class instance
> property can not change their reference, it is impossible to replace zval
> in such property, in my opinion `immutable` is object behavior when using
> some methods you receive newly created (cloned) object which is changed
> exactly like `DateTimeImmutable`
> http://php.net/manual/en/datetimeimmutable.add.php
>

I am aware of what `final` means in other languages, it just seems that
everyone then needs to translate back and forth from `final` to
`immutable`. In addition to that, `final` has different meaning in
inheritance (re-used keyword), so this adds to the confusion for people
unfamiliar with the feature.


> Ad. 3 it would be awesome if there could be final variables in general, it
> would be quite stable if no one could change your variable, AFAIK zvals
> have IMMUTABLE flag which could be used, don't know it for sure I'm rather
> PHP dev than C there would be need some internals guru to ask if it's
> posiible.
>
> P.S. We've meet on PHPCon'15 in Poland, thanks for +1.
>

YW!


>
> Cheers,
> --
> Michał Brzuchalski (aka brzuchal)
>
> 2016-04-05 11:13 GMT+02:00 Marco Pivetta :
>
>> Hi Michał,
>>
>> First of all: +1 to this: very useful for value objects!
>>
>> A few questions:
>>
>>  * can you re-declare a final property in a sub-class, making it
>> therefore non-final? (I have reasons to do that, related with altering
>> states via mappers)
>>  * do we want to use `final`, or `immutable` for these properties?
>> `final` seems to just be a confusing term here.
>>  * is this feature portable to variables in general? I realize that
>> adding metadata to ZVals has huge performance implications, but it would be
>> interesting to do that for performance improvements further down the line
>>
>> Cheers,
>>
>>
>> Marco Pivetta
>>
>> http://twitter.com/Ocramius
>>
>> http://ocramius.github.com/
>>
>> On 4 April 2016 at 19:53, Michał Brzuchalski 
>> wrote:
>>
>>> Hey Internals,
>>>
>>> I'm new here. I've been wondering / working on adding final properties
>>> into
>>> PHP lang.
>>>
>>> This work started once I had the time to read the "Core Java for
>>> Impateient" by Cay S. Horstmann
>>> and found it very usefull to have final properties like Java.
>>>
>>> Those properties differ than `const` because they can be set at runtime -
>>> but only once in their lifetime.
>>> Such properties could be very usefull in Singletons, ValueObjects etc.
>>> impl
>>> like:
>>>
>>> class Money {
>>> public final $amount;
>>> public final $currency;
>>> public function __constructor($amount, $currency) {
>>> $this->amount = $amount;
>>> $this->currency = $currency;
>>> }
>>> }
>>>
>>> In above example there is even no need for getter because those
>>> properties
>>> are immutable through
>>> the final keyword, it means those properties cannot change their
>>> references
>>> just like in Java
>>> https://en.wikipedia.org/wiki/Final_(Java)
>>>
>>> I've already started some impl on own fork
>>> https://github.com/php/php-src/compare/master...brzuchal:final-properties
>>> I've got some basics in C programming, don't know yet if I can impl it
>>> complex.
>>>
>>> I was wondering if it is usefull in yours opinion or is it only my
>>> impression.
>>>
>>> I can provide an RFC if it sounds usefull and if I get Wiki karma
>>>
>>> Thanks
>>> --
>>> Michał Brzuchalski (aka brzuchal)
>>>
>>
>>
>
As an additional question: how will this (eventually) play with typed
properties? I am aware that you cannot declare a class named `final`, but
that may change in future, so better factor it into any possible outcomes
of the RFC.

Cheers,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Final properties

[Michał Brzuchalski]

Hi Marco,

Ad. 1 it is posiible to redeclare in a sub-class final property as
non-final, here is some gist presenting my current impl working like:
https://gist.github.com/brzuchal/12ebda1efed59440a78ba43bff116728

Ad. 2. `final` means class variable (like static) or class instance
property can not change their reference, it is impossible to replace zval
in such property, in my opinion `immutable` is object behavior when using
some methods you receive newly created (cloned) object which is changed
exactly like `DateTimeImmutable`
http://php.net/manual/en/datetimeimmutable.add.php

Ad. 3 it would be awesome if there could be final variables in general, it
would be quite stable if no one could change your variable, AFAIK zvals
have IMMUTABLE flag which could be used, don't know it for sure I'm rather
PHP dev than C there would be need some internals guru to ask if it's
posiible.

P.S. We've meet on PHPCon'15 in Poland, thanks for +1.

Cheers,
--
Michał Brzuchalski (aka brzuchal)

2016-04-05 11:13 GMT+02:00 Marco Pivetta :

> Hi Michał,
>
> First of all: +1 to this: very useful for value objects!
>
> A few questions:
>
>  * can you re-declare a final property in a sub-class, making it therefore
> non-final? (I have reasons to do that, related with altering states via
> mappers)
>  * do we want to use `final`, or `immutable` for these properties? `final`
> seems to just be a confusing term here.
>  * is this feature portable to variables in general? I realize that adding
> metadata to ZVals has huge performance implications, but it would be
> interesting to do that for performance improvements further down the line
>
> Cheers,
>
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
> On 4 April 2016 at 19:53, Michał Brzuchalski 
> wrote:
>
>> Hey Internals,
>>
>> I'm new here. I've been wondering / working on adding final properties
>> into
>> PHP lang.
>>
>> This work started once I had the time to read the "Core Java for
>> Impateient" by Cay S. Horstmann
>> and found it very usefull to have final properties like Java.
>>
>> Those properties differ than `const` because they can be set at runtime -
>> but only once in their lifetime.
>> Such properties could be very usefull in Singletons, ValueObjects etc.
>> impl
>> like:
>>
>> class Money {
>> public final $amount;
>> public final $currency;
>> public function __constructor($amount, $currency) {
>> $this->amount = $amount;
>> $this->currency = $currency;
>> }
>> }
>>
>> In above example there is even no need for getter because those properties
>> are immutable through
>> the final keyword, it means those properties cannot change their
>> references
>> just like in Java
>> https://en.wikipedia.org/wiki/Final_(Java)
>>
>> I've already started some impl on own fork
>> https://github.com/php/php-src/compare/master...brzuchal:final-properties
>> I've got some basics in C programming, don't know yet if I can impl it
>> complex.
>>
>> I was wondering if it is usefull in yours opinion or is it only my
>> impression.
>>
>> I can provide an RFC if it sounds usefull and if I get Wiki karma
>>
>> Thanks
>> --
>> Michał Brzuchalski (aka brzuchal)
>>
>
>

Re: [PHP-DEV] RETURN micro optimization

[Joe Watkins]

Morning Derick,

I don't think it does make anything impossible, it's just a more
efficient copying method in the EXPECTED branch is all.

Cheers
Joe

On Tue, Apr 5, 2016 at 10:04 AM, Derick Rethans  wrote:

> On Tue, 5 Apr 2016, Dmitry Stogov wrote:
>
> > I propose a micro optimization for RETURN statement.
> >
> > Currently "return $x" increments reference counter of $x, then in
> > zend_leave_helper() we perform zval_ptr_dtor() on the same $x.
> >
> > The patch sets the original value of $x to null in first place, so
> > zval_ptr_dtor() is not going to be called.
> >
> > https://gist.github.com/dstogov/36f68b206242a39691ac539c2fc85d40
> >
> > the performance impact is invisible (0.1% less instruction retired on
> > Wordpress).
> >
> > It breaks sapi/phpdbg/tests/breakpoints_005.phpt, but this is probably
> > not a big deal.
> >
> > BTW: this change may affect debuggers in some other way.
>
> I'd like to know why this breaks before saying something. It'd be a PITA
> if this micro optimisation wouldn't actually do a lot performance wise,
> but makes some debugging not possible.
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Final properties

[Marco Pivetta]

Hi Michał,

First of all: +1 to this: very useful for value objects!

A few questions:

 * can you re-declare a final property in a sub-class, making it therefore
non-final? (I have reasons to do that, related with altering states via
mappers)
 * do we want to use `final`, or `immutable` for these properties? `final`
seems to just be a confusing term here.
 * is this feature portable to variables in general? I realize that adding
metadata to ZVals has huge performance implications, but it would be
interesting to do that for performance improvements further down the line

Cheers,


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 4 April 2016 at 19:53, Michał Brzuchalski  wrote:

> Hey Internals,
>
> I'm new here. I've been wondering / working on adding final properties into
> PHP lang.
>
> This work started once I had the time to read the "Core Java for
> Impateient" by Cay S. Horstmann
> and found it very usefull to have final properties like Java.
>
> Those properties differ than `const` because they can be set at runtime -
> but only once in their lifetime.
> Such properties could be very usefull in Singletons, ValueObjects etc. impl
> like:
>
> class Money {
> public final $amount;
> public final $currency;
> public function __constructor($amount, $currency) {
> $this->amount = $amount;
> $this->currency = $currency;
> }
> }
>
> In above example there is even no need for getter because those properties
> are immutable through
> the final keyword, it means those properties cannot change their references
> just like in Java
> https://en.wikipedia.org/wiki/Final_(Java)
>
> I've already started some impl on own fork
> https://github.com/php/php-src/compare/master...brzuchal:final-properties
> I've got some basics in C programming, don't know yet if I can impl it
> complex.
>
> I was wondering if it is usefull in yours opinion or is it only my
> impression.
>
> I can provide an RFC if it sounds usefull and if I get Wiki karma
>
> Thanks
> --
> Michał Brzuchalski (aka brzuchal)
>

Re: [PHP-DEV] IntlCharsetDetector

[Derick Rethans]

On Mon, 4 Apr 2016, Sara Golemon wrote:

> The subject of character set detection (yes, I know, a hard problem to
> solve) came up on SO chat, and Niki noticed that we don't yet wrap the
> ICU UCharsetDetector API so I volunteered to put something together.
> 
> https://github.com/php/php-src/compare/master...sgolemon:intl.charsetdetector
> 
> The trouble is, for the WIDE majority of my test cases so far, ICU is
> really bad at detecting character sets correctly (as I said, it's a
> tough problem).  In fact, the ICU manual admits that it doesn't even
> look at all of the corpus text, and the "language detection" is a
> byproduct not meant for actual language detection.
> 
> Given all that, I'm inclined to reject the idea of rolling this into
> PHP for fear of just confusing users without actually adding any
> value.
> 
> Thoughts?

I would advice against adding this.

As you say, it doesn't work properly. As a matter of fact, guessing 
charsets, like timezones, is not possible. You need to know which 
charset something is in. If not, you need to address *that* problem.

cheers,
Derick

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

Re: [PHP-DEV] RETURN micro optimization

[Derick Rethans]

On Tue, 5 Apr 2016, Dmitry Stogov wrote:

> I propose a micro optimization for RETURN statement.
> 
> Currently "return $x" increments reference counter of $x, then in 
> zend_leave_helper() we perform zval_ptr_dtor() on the same $x.
> 
> The patch sets the original value of $x to null in first place, so 
> zval_ptr_dtor() is not going to be called.
> 
> https://gist.github.com/dstogov/36f68b206242a39691ac539c2fc85d40
> 
> the performance impact is invisible (0.1% less instruction retired on 
> Wordpress).
> 
> It breaks sapi/phpdbg/tests/breakpoints_005.phpt, but this is probably 
> not a big deal.
> 
> BTW: this change may affect debuggers in some other way.

I'd like to know why this breaks before saying something. It'd be a PITA 
if this micro optimisation wouldn't actually do a lot performance wise, 
but makes some debugging not possible.

cheers,
Derick

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

Re: [PHP-DEV] RETURN micro optimization

[Pierre Joye]

On Tue, Apr 5, 2016 at 2:59 PM, Dmitry Stogov  wrote:
> Hi,
>
>
> I propose a micro optimization for RETURN statement.
>
> Currently "return $x" increments reference counter of $x, then in 
> zend_leave_helper() we perform zval_ptr_dtor() on the same $x.
>
> The patch sets the original value of $x to null in first place, so 
> zval_ptr_dtor() is not going to be called.
>
>
> https://gist.github.com/dstogov/36f68b206242a39691ac539c2fc85d40
>
>
> the performance impact is invisible (0.1% less instruction retired on 
> Wordpress).
>
>
> It breaks sapi/phpdbg/tests/breakpoints_005.phpt, but this is probably not a 
> big deal.
>
> BTW: this change may affect debuggers in some other way.

I suppose it is for 7.1 anyway, right? so debugger will have to be
ported but it would be nice to know exactly how this change will
affect them to make sure that users can migrate to 7.1 smoothly and
still use their tools.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

[PHP-DEV] RETURN micro optimization

[Dmitry Stogov]

Hi,


I propose a micro optimization for RETURN statement.

Currently "return $x" increments reference counter of $x, then in 
zend_leave_helper() we perform zval_ptr_dtor() on the same $x.

The patch sets the original value of $x to null in first place, so 
zval_ptr_dtor() is not going to be called.


https://gist.github.com/dstogov/36f68b206242a39691ac539c2fc85d40


the performance impact is invisible (0.1% less instruction retired on 
Wordpress).


It breaks sapi/phpdbg/tests/breakpoints_005.phpt, but this is probably not a 
big deal.

BTW: this change may affect debuggers in some other way.


Let me know, if you see any problems (I'll delay commit for 2-3 days).


Thanks. Dmitry.