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
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 cornelius.howl@gmail.com
Sent: Sunday, April 3, 2016 11:10
To: Xinchen Hui
Cc: Dmitry Stogov; internals; Nikita Popov
Subject: Re: Object getter method optimizationI submitted the new benchmark result here:
Benchmark Result Getter Method Only
https://gist.github.com/8cd230a5601cbe38439661adf3caca0d
Without getter optimization (3 runs):
151.0169506073msWith getter optimization (3 runs)
39.201021194458ms
Template Engine Benchmarkhttps://gist.github.com/a23cf294dfcf74683b8f02d93a47bc5b
With getter optimization:
1118msWithout getter optimization:
1235ms
AffectOther Microbench result:
https://gist.github.com/c9s/0273ac21631562724cabf86c42e86e32On Sat, Apr 2, 2016 at 11:29 AM, Lin Yo-An cornelius.howl@gmail.com
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 laruence@php.net 於 2016年4月1日 星期五寫道:
Hey:
On Fri, Apr 1, 2016 at 4:35 PM, Lin Yo-An cornelius.howl@gmail.com
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:
In compile-time, the pass_two() function now marks the getter
functions in op_array.accessor.typeWhen 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?<?php
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
- 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:
Added accessor struct to op_array to save "accessor" related
information (getter or setter, property offset)Added two statement in zend_std_read_property to save property
offset.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
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 cornelius.howl@gmail.com
Sent: Saturday, March 19, 2016 10:08
To: Dmitry Stogov
Cc: internals; Xinchen Hui
Subject: Re: [PHP-DEV] Object getter method optimizationHi 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.phpwhen main.php is compiled, we don't know what the class entry of
$worker is. What we only know is invoking a method "getStatus" on $worker
CV unless we know we have to compile worker.php before main.php and add a
type hint on $worker.Is it correct?
Since the original approach doesn't work, here comes another new idea:
When executing method call on an object, if we found the method body
are just 2 op codes (FETCH_OBJ_R and RETURN), we then denote the method is
a "getter method"And the next time, when we execute the same method, we found the
"getter method" flag, we simply execute FETCH_OBJ_R on that object and
return the value to avoid extra op code execution time.Do you think if this could work?
Best Regards and Thanks for your work on PHP VM
Yo-An LinOn Fri, Mar 18, 2016 at 3:36 PM, Dmitry Stogov dmitry@zend.com
wrote:Hi Yo-An Lin,
Unfortunately, this approach won't work.
At first, at compile time we don't know the body of called getter.
At second, the called method might be changed even at run-time,
because of polymorphism.Tricks like this might be implemented using JIT and polymorphic
inline caches.Thanks. Dmitry.
From: Lin Yo-An cornelius.howl@gmail.com
Sent: Friday, March 18, 2016 05:23
To: internals
Subject: [PHP-DEV] Object getter method optimizationHello Everyone,
I am recently trying to write an optimizer that could optimize the
getter
method call into just one object fetch opcode.I'd like to know thoughts from you guys, here is the note:
https://c9s.hackpad.com/INLINE-OP-TVGo9WcshbZ--
Best Regards,Yo-An Lin
https://github.com/c9s--
Best Regards,Yo-An Lin
--
Best Regards,Yo-An Lin
--
Xinchen Hui
@Laruence
http://www.laruence.com/--
Sent from Gmail Mobile--
Best Regards,Yo-An Lin
--
Best Regards,
Yo-An Lin
sorry, one typo, the "op_array->type" should be "op_array->fn_flags"
I updated my PR here
https://github.com/php/php-src/pull/1847/files#diff-3054389ad750ce9a9f5895cd6d27800fR3159
sorry, one typo, the "op_array->type" should be "op_array->fn_flags"
--
Best Regards,
Yo-An Lin
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.