Re: [PHP-DEV] [RFC] Nullable Types

[Lin Yo-An]

On Wed, Apr 20, 2016 at 11:05 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
>
> Dmitry is even involved in the discussion of having IS_UNDEF until
> constructor ends, then enforcing type hinting at the end of constructor to
> trigger potential invalid instance state. It created a mess in the internal
> structure by creating a 3-state value: uninitialized, absent of value
> (null) and assigned value. All this problem would be solved by merging null
> into accepted value.
> So far the proposed solution there to take a wrong assumption to assume a
> default value based on type defined (like int = 0, string = '', etc), which
> are all potential valid values, leading to unpredictable behavior if a
> develop misses to assign a value to that property.
>

> Sure, people will say that now PHP will require a NullPointerException,
> PHP is turning into Java, or that I don't know what I'm talking about
> because they coded for Amiga and I don't (yes, I've seen that already in
> this mailing list). But the fact is that keeping control of 3-state flags
> are hard to maintain.
>

I think this is not to make PHP like Java, and it totally makes sense -
Nullable should be a type of a type instead of a state. In Haskell it's
named Maybe or Option, and It's better than NullPointerException.

Here is a discussion from Haskell community:
https://mail.haskell.org/pipermail/haskell-cafe/2011-April/091269.html

-- 
Best Regards,

Yo-An Lin

Re: [PHP-DEV] [RFC] Nullable Types

[Lin Yo-An]

On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov  wrote:

> The grammar is taken from HHVM.
> Using any other would make more mess.
>
I agree

Re: [PHP-DEV] [RFC] Union Types

[Lin Yo-An]

I think it will be better if union type is only allowed in the "type"
statement, like what you described in your RFC.

type Iterable = Array  | Traversable;

If we can always pre-define the types.

And only allow just one type for each function parameter in the function
prototype, then, I think the performance impact of type checking in the
runtime might be able to be reduced.

In other words, you predefine the union type before you used them, and the
union types can be reused in different functions, you don't write a lot
union type in function prototype.

Re: [PHP-DEV] Re: Improving PHP's type system

[Lin Yo-An]

On Sun, Apr 17, 2016 at 6:06 AM, Bastian Schneider <
bastian.schnei...@commerce-plus.com> wrote:

> Just a quick thought.
>
>
> union Iterable {
> use array;
> use ArrayAccess;
> use Traversable;
> }
>

I think this example creates another meaning on the "use" syntax, which
make "use" context depended.

The "use" statement is already used to "create an class name alias in the
current namespace." and this makes "use" confusing.



Thanks, Yo-An Lin

Re: [PHP-DEV] Trying to fix "use" language inconsistencies

[Lin Yo-An]

I thought there was one already?
https://wiki.php.net/rfc/group_use_declarations

On Sat, Apr 16, 2016 at 9:01 AM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> Hi internals,
>
>
> It all started with a PR over doctrine/annotations (
> https://github.com/doctrine/annotations/pull/69), where a contributor
> decided to propose supporting group use support.
>
> The issue starts with this, which it is perfectly supported:
>
> use Foo\Bar, Foo\Woo;
>
> While multiple group uses are not:
>
> use Foo\{Bar, Baz}, Qux\{Corge, Grault};
>
> Then I decided to see what is really supported by the newly introduced
> group use. According to the grammar, these are the same lines:
>
> use Foo\Bar, Foo\Baz;
> use Foo\{Bar, Baz};
>
> use function Foo\Bar\baz, Foo\Bar\qux;
> use function Foo\Bar\{baz, qux};
> use Foo\Bar\{function baz, function qux};
>
> However, this feature leads to an inconsistent behavior in the language.
> Mixed group use types are supported:
>
> use Foo\Bar\{Baz, function qux};
>
> While mixing use types are not:
>
> use Foo\Bar\Baz, function Foo\Bar\qux;
>
>
> This brings the question of whether we should continue this madness path of
> inconsistency or we start addressing inconsistencies one by one in the
> language.
> I'd like to propose options that we could fix this:
>
> - Remove mixed group use types support (this would become invalid: use
> Foo\{Bar, function baz};)
> - Add mixed use support, which would contradict the approach took by typed
> properties (this would require this approach: use function Foo\Bar\baz,
> function Foo\Bar\qux;)
>
> One of the approaches needs to be taken in order to support multiple group
> use, otherwise we have a reduce/reduce yacc error that can't be fixed
> (well, my yacc/compiler's knowledge hit a dead end there, without doubling
> all the grammar rules and taking an overly complex route). Ultimately, the
> question comes around if we should consider support of multiple group use.
> If positive, I'd suggest approach two (I already have a patch for that!
> =D).
>
>
> I'd like to gather opinions around this, so I can properly implement and
> propose a patch through an RFC process.
>
>
> Regards,
>
> --
> Guilherme Blanco
> Lead Architect at E-Block
>



-- 
Best Regards,

Yo-An Lin

Re: [PHP-DEV] Re: Improving PHP's type system

[Lin Yo-An]

If we can pre-define the types via something like this:

data Tree a = Branch (Tree a) (Tree a) | Leaf a


And only allow one type for each function parameter in the prototype, then,
I think the performance impact of type checking in the runtime can be
reduced.

In other words, you predefine the union type before you used them, and the
union types can be reused in different functions, you don't write a lot
union type in function prototype.

For example,

   typedef T = array | Traversable

   function foo(T $a) {  }
   function bar(T $b) {  }

Re: [PHP-DEV] Re: Improving PHP's type system

[Lin Yo-An]

I pretty much like the Haskell type system, it let you define types via the
syntax below:

data Tree a = Branch (Tree a) (Tree a) | Leaf a


But the type inference in Haskell can be resolved in the compile-time. We
can only verify the variable type for each function call in PHP.

Re: [PHP-DEV] Re: Improving PHP's type system

[Lin Yo-An]

On Sat, Apr 16, 2016 at 1:28 AM, Christoph Becker  wrote:

> On 15.04.2016 at 17:42, Larry Garfield wrote:
>
> Maybe we should consider to accept an array as Traversable?  Actually, I
> wonder why that's not already the case.
>

+1, I think so too.


-- 
Best Regards,

Yo-An Lin

Re: [PHP-DEV] Improving PHP's type system

[Lin Yo-An]

Andrea Faulds  於 2016年4月15日 星期五寫道：
>
>
> This is something that particularly concerns me about union types, in that
> they reduce type safety. If you have a union type of Foo|Bar for some
> variable, then the set of methods you can call on that variable is actually
> the intersection, not the union, of the set of methods you can call on Foo
> and Bar. Which, unless those two classes share some interface, is probably
> an empty set. So there's nothing you can actually do safely with it without
> doing checks within the body of the function, and if you're doing that,
> then why do we have a type declaration? It's only barely more useful than
> omitting a type declaration at all; type declarations are supposed to
> prevent you needing to check. On the other hand, if the two classes share
> some methods, then either there's an interface you can already use here, or
> you can create one. Either way, you don't need a union type.

+1 I agree. Language like Golang use interface to intersect the method
calls, I think that's better.



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

-- 
Sent from Gmail Mobile

[PHP-DEV] Re: optimization for function call without paremters

[Lin Yo-An]

I think this optimization could be done by two approach:

1. Add another FCALL op, which init a function call and call that function
directly for functions without parameters.

2. Let the original INIT_FCALL support "call function when the number of
parameter == 0"

On Fri, Apr 15, 2016 at 5:27 PM, Lin Yo-An <cornelius.h...@gmail.com> wrote:

> Hi Dmitry,
>
>
> I found that INIT_FCALL doesn't use opline->result.var and DO_ICALL
> doesn't use op1 or op2. The original purpose of separating these two op was
> for sending parameters.
>
> However, if a function doesn't need parameters and it's an internal
> function, I think the operation could be merged into INIT_FCALL.
>
> So I guess we can do this below to reduce one bytecode for each function
> call without parameters:
>
> if (opline->extended_value == 0) {
>  // call the function directly and store the value in the result.
> }
>
> Your thoughts?
>
>
>
>
> Best Regards,
>
> Yo-An Lin
>



-- 
Best Regards,

Yo-An Lin

[PHP-DEV] optimization for function call without paremters

[Lin Yo-An]

Hi Dmitry,


I found that INIT_FCALL doesn't use opline->result.var and DO_ICALL doesn't
use op1 or op2. The original purpose of separating these two op was for
sending parameters.

However, if a function doesn't need parameters and it's an internal
function, I think the operation could be merged into INIT_FCALL.

So I guess we can do this below to reduce one bytecode for each function
call without parameters:

if (opline->extended_value == 0) {
 // call the function directly and store the value in the result.
}

Your thoughts?




Best Regards,

Yo-An Lin

Re: [PHP-DEV] Re: Improving PHP's type system

[Lin Yo-An]

On Thu, Apr 14, 2016 at 5:44 PM, Alain Williams  wrote:

> On Thu, Apr 14, 2016 at 10:00:41AM +0100, Tony Marston wrote:
>
> > I agree with Zeev 100%. There are too many people out there who are
> > trying to make the language more complicated than it need be just to
> > prove how clever they are. The aim of any language should be to
> > enable programmers to do complicated things in a simple way, and not
> > to do simple things in a complicated way.
>
> I disagree. My way of looking at it is that adding some features(eg the
> current
> type specification/checking) adds to the simplicity because I can say what
> types
> I want and don't need to write code to check the types of argument
> received by a
> function (etc).

Why would I want to check: because I value robustness, ie not having my code
> fall over because, somehow, a wrong type slips by unnoticed.



I think the original purpose of adding type system in Hack, is to provide
just-in-time compilation, this provides more information to let compiler to
optimize the code with specific type.

Haskell, OCaml, C or C++, these statically typed languages compile code
into executable binary, the compiler raises the warnings or errors before
executing it, thus they have more time to check type information, they
usually don't check type in the run-time.

However PHP is not, PHP runs script on the fly, and check the type in the
runtime (instead of compile time), therefore the type checking implemented
in PHP is a kind of execution performance trade off (until we implemented
the JIT compiler). and a complex type system add more extra work to the
whole system than statically typed language.

Adding type hinting makes people writing PHP code with more confident, I
like the scalar type hinting implemented in the current PHP.

But weak type conversion and union type are not, it introduces more complex
rules of how variables should be converted into another values, and there
will be more implementation defined behavior. People will have to always
have a cheatsheet or something to check whether if they write the correct
code.

And I believe, if we can remove the support of weak type conversion, PHP
could be a "consistent", "simple" language and it can help people write
confident code.



Cheers, Yo-An Lin

Re: [PHP-DEV] [RFC] Union Types

[Lin Yo-An]

Derick Rethans <der...@php.net> 於 2016年4月14日 星期四寫道：

> On Thu, 14 Apr 2016, Lin Yo-An wrote:
>
> > On Thu, Apr 14, 2016 at 5:12 PM, Derick Rethans <der...@php.net
> <javascript:;>> wrote:
> > I think type conversion shouldn't be done internally, implicitly.
> >
> > Implicit conversion leads more confusion in the language. when you
> > pass variables, you have to remember these conversion rules.
>
> Sorry, we already have this with our weak scalar types. You can't make
> union types not work with that.


>
Does Hack support weak type conversion?




-- 
Sent from Gmail Mobile

Re: [PHP-DEV] [RFC] Union Types

[Lin Yo-An]

On Thu, Apr 14, 2016 at 5:12 PM, Derick Rethans  wrote:

> I think what I am missing in the RFC is behaviour with scalar (weak)
> typehints, and which type the variable in a class would be converted to.
> Take for example:
>
> function foo(int|bool $var) { echo get_type( $var ), "\n"; }
>
> foo(5); I guess int(5)
> foo(false); I guess bool(false)
> foo(0.5);   It could be either int(1) or bool(true)
>
> And what if the hint would be "bool|int" ?
>

I think type conversion shouldn't be done internally, implicitly.

Implicit conversion leads more confusion in the language. when you pass
variables, you have to remember these conversion rules.

type conversion should be done in the caller, that's why typed language
like C or C++ ask you to convert the type manually before you pass the
variable into a function.




-- 
Best Regards,

Yo-An Lin

Re: [PHP-DEV] [RFC] Union Types

[Lin Yo-An]

I think this will add more complexity to the runtime system. The type
hinting will be something we use to generate good JIT code, not just for
checking types.


Dmitry Stogov  於 2016年4月14日 星期四寫道：

> The RFC doesn't say anything about support for multiple class names.
>
> function foo(A|B|C $x)
>
> Support for multiple classes would lead to complex implementation.
>
> Thanks. Dmitry.
>
> 
> From: Levi Morrison >
> Sent: Thursday, April 14, 2016 06:46
> To: internals
> Subject: [PHP-DEV] [RFC] Union Types
>
> As alluded to in an earlier email today[1] I am now moving the Union
> Types RFC[2] to the discussion phase. The short summary of the RFC is
> that it permits a type declaration to be one of several enumerated
> types. For example, this is a potential signature for a multi-type map
> routine:
>
> function map(callable $f, Array | Traversable $iterable);
>
> The second parameter `$iterable` is required to be of type Array or
> Traversable - any other type will error.
>
> I look forward to a helpful and meaningful discussion!
>
>   [1]: http://news.php.net/php.internals/92252
>   [2]: https://wiki.php.net/rfc/union_types
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Sent from Gmail Mobile

[PHP-DEV] Proposal: Startup snapshot for optimizing app load time

[Lin Yo-An]

Hi internals,


The javascript engine V8 uses a strategy called "startup snapshot" to
optimize app load time (see
http://v8project.blogspot.tw/2015/09/custom-startup-snapshots.html for more
details)

The approach used by V8 creates a snapshot from heap, so the V8Context
could be reused directly without re-running the bootstraping code.

I think running javascript app in the browser is somehow like we run php
script for each requests where the app bootstrapping code is required to be
executed repeatedly for each request.

Currently, our opcache extension can cache the byte codes, but the byte
codes still need to be executed every time when bootstrapping an app, and
which increases the overhead for each request.

For example, a lot of applications use composer to initialize the class
loader via the statement below:

require "vendor/autoload.php";

The statement above produces thousands of byte code to run, which is to
make an app ready. (If you use vld extension to show the opcodes)

However, if we can support a simple syntax to describe what is doing
"bootstrap", we are able to create a startup snapshot from it.


The proposal here want to introduce some new syntax to optimize app load
time though the below syntax:

bootstrap "vendor/autoload.php";  // caches the context after running
this script.

Or

bootstrap {
   require "vendor/autoload.php";
   // do something else for making app ready
};

And of course, we might detect the bootstrap script automatically without
creating new syntax and opcodes, but I think it's hard to do because PHP
applications can be written by many ways...


Questions


I don't know if this approach is doable or not. Or maybe we can support
this in a separated extension instead of changing the zend core?

Do you guys think it's doable? would you like to share your idea for this?






Best Regards,

Yo-An Lin

[PHP-DEV] Re: Object getter method optimization

[Lin Yo-An]

On Mon, Apr 11, 2016 at 11:53 PM, Dmitry Stogov  wrote:

> Or... maybe we shall move the function info related functions into the
> core? since we might have some optimization based on the function info
> instead of optimizing opcode only in the future.
>
> We consider, possibility of moving the whole Optimizer into Zend, but it
> won't change a lot, because expensive optimization make sense only with
> opcache (when script is optimized once and executed many times).
>

Is this something I can help? I mean, moving the core of func info into the
core.

I think I might need to postpone the accessor optimization before the
func_info is integrated into the core since it's the best place to store
the accessor information.



Best Regards,

Yo-An Lin

[PHP-DEV] Re: Object getter method optimization

[Lin Yo-An]

On Mon, Apr 11, 2016 at 11:53 PM, Dmitry Stogov  wrote:
>
>

> We consider, possibility of moving the whole Optimizer into Zend, but it
> won't change a lot, because expensive optimization make sense only with
> opcache (when script is optimized once and executed many times).
>

Do you (or the team?) prefer to keep the JIT implementation as an extension
or integrate the JIT implementation into the Zend core?


Thanks, Yo-An

[PHP-DEV] Re: Object getter method optimization

[Lin Yo-An]

Hi Dmitry,

How's it going?

I traversed the code of opcache extension, and just found the FUNC_INFO
related macros.  I guess the accessor information is more like an entry
that should be put in the function info.

Or... maybe we shall move the function info related functions into the
core? since we might have some optimization based on the function info
instead of optimizing opcode only in the future.

And I think the function info we pre-processed in the compile-time would
help JIT to compile the opcode a lot.

By the way, would you mind to let me know the plan of implementing the JIT
compilation in PHP? I saw your zend-jit branch is using LLVM as the backend.

In my experience, LLVM compiles large code a lot of slower.  what do you
think of using DynASM as the JIT backend?

V8 compiles ast nodes into native code directly without
interpreting/translating the op codes, I don't know if it's a good approach
to try. your thoughts?


Cheers, Yo-An

Re: [PHP-DEV] Final properties

[Lin Yo-An]

I would prefer putting the "final" keyword before the "public".

final public $items;

Since we should emphasis "final" rather than "public"

[PHP-DEV] Re: Object getter method optimization

[Lin Yo-An]

Yeah I know. I've saw that yesterday.

[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 <cornelius.h...@gmail.com> 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

[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 <dmi...@zend.com> 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 <cornelius.h...@gmail.com>
> *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 <cornelius.h...@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 <larue...@php.net> 於 2016年4月1日 星期五寫道：
>>
>> Hey:
>>>
>>> On Fri, Apr 1, 2016 at 4:35 PM, Lin Yo-An <cornelius.h...@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:
>>>>
>>>> 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 yo

[PHP-DEV] Re: Object getter method optimization

[Lin Yo-An]

I submitted the new benchmark result here:

Benchmark ResultGetter 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 <cornelius.h...@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 <larue...@php.net> 於 2016年4月1日 星期五寫道：
>
> Hey:
>>
>> On Fri, Apr 1, 2016 at 4:35 PM, Lin Yo-An <cornelius.h...@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:
>>>
>>> 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 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 <dmi...@zend.com> 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.
>>>>
>>>>
>>>>

[PHP-DEV] Re: Object getter method optimization

[Lin Yo-An]

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 <larue...@php.net> 於 2016年4月1日 星期五寫道：

> Hey:
>
> On Fri, Apr 1, 2016 at 4:35 PM, Lin Yo-An <cornelius.h...@gmail.com
> <javascript:_e(%7B%7D,'cvml','cornelius.h...@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:
>>
>> 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 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 <dmi...@zend.com
>> <javascript:_e(%7B%7D,'cvml','dmi...@zend.com');>> 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 <cornelius.h...@gmail.com
>>> <javascript:_e(%7B%7D,'cvml','cornelius.h...@gmail.com');>>
>>> *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
>>>
>>

Re: [PHP-DEV] Object getter method optimization

[Lin Yo-An]

I submitted my PR here https://github.com/php/php-src/pull/1847

On Fri, Apr 1, 2016 at 11:41 PM, Lin Yo-An <cornelius.h...@gmail.com> wrote:

> Hi internals,
>
>
> Here comes the result:
>
> Without getter optimization (3 runs):
>
> 250.76603889465ms
>
> With getter optimization (3 runs)
>
> 110.88299751282ms
>
>
> Microbench result:
> https://gist.github.com/c9s/0273ac21631562724cabf86c42e86e32
>
>
>
>
> On Fri, Apr 1, 2016 at 4:35 PM, Lin Yo-An <cornelius.h...@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:
>>
>> 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".
>>
>> 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 <dmi...@zend.com> 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 <cornelius.h...@gmail.com>
>>> *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 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 execu

Re: [PHP-DEV] Object getter method optimization

[Lin Yo-An]

Hi internals,


Here comes the result:

Without getter optimization (3 runs):

250.76603889465ms

With getter optimization (3 runs)

110.88299751282ms


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




On Fri, Apr 1, 2016 at 4:35 PM, Lin Yo-An <cornelius.h...@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:
>
> 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".
>
> 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 <dmi...@zend.com> 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 <cornelius.h...@gmail.com>
>> *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 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 Lin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Mar 18, 2016 at 3:36 PM, Dmitry Stogov <dmi...@zend.com> wrote:
>>
>>> Hi Yo-An Lin,
>>>
>>> Unfortunately, this approach won't work.
>>

Re: [PHP-DEV] Object getter method optimization

[Lin Yo-An]

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".

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 <dmi...@zend.com> 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 <cornelius.h...@gmail.com>
> *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 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 Lin
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Mar 18, 2016 at 3:36 PM, Dmitry Stogov <dmi...@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.h...@gmail.com>
>> Sent: Friday, March 18, 2016 05:23
>> To: internals
>> Subject: [PHP-DEV] Object getter method optimization
>>
>> Hello 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

[PHP-DEV] Re: Object getter method optimization

[Lin Yo-An]

>
>
>> I was playing with this idea sometime ago, it gives good performance
> boost for code like `for ($i = 0; $i < 10; $i++) $a->getFoo();` but in
> the end of the day it's a very limited optimization.
> If you abstract away from getters and say you want to optimize more and
> more small functions like this one, you end up realizing that what you're
> actually doing is what JIT compilation would do in a more generic way.


I agree with you that JIT could achieve this.

Although this could be done by JIT, however the JIT approach would require
good code generation to produce efficient getter code to return the
property value, and there will be a JIT threshold and extra compilation
time for caller to reach.







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

-- 
Sent from Gmail Mobile

[PHP-DEV] Object getter method optimization

[Lin Yo-An]

Hello 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

Re: [PHP-DEV] Object getter method optimization

[Lin Yo-An]

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 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 Lin































On Fri, Mar 18, 2016 at 3:36 PM, Dmitry Stogov <dmi...@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.h...@gmail.com>
> Sent: Friday, March 18, 2016 05:23
> To: internals
> Subject: [PHP-DEV] Object getter method optimization
>
> Hello 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

Re: [PHP-DEV] few questions about op_array

[Lin Yo-An]

Hi Hui,

On Fri, Oct 23, 2015 at 8:27 PM, Xinchen Hui <larue...@php.net> wrote:

> Hey Lin:
>
> On Fri, Oct 23, 2015 at 3:31 PM, Lin Yo-An <cornelius.h...@gmail.com>
> wrote:
>
>> Hi Dmitry,
>>
>>
>> I changed and tested it, and it looks like it gains some improvements.
>> how do you compare the benchmark result? is there a tool doing it?
>>
>> I currently do:
>>
>> ./sapi/cli/php Zend/bench.php
>>
>> The result:
>>
>> https://gist.github.com/4bbc33b7b5dcedc6bd66
>>
> Acutally, simply bench.php testing is very un-stable. in generally, we
> prefer using real-life app to test, like wordpress.
>
> Basically, we use callgrind to collect the IRs ,  like valgrind
> --tool=callgrind --instr-atstart=yes php-cgi -T 100 wordpress/index.php ( I
> may type args wrong).
>
> But in this case(cache friendly), you may try to use perf to collect cache
> miss changing.
>

Thanks! it's helpful!

Re: [PHP-DEV] few questions about op_array

[Lin Yo-An]

Hi Dmitry,


I changed and tested it, and it looks like it gains some improvements. how
do you compare the benchmark result? is there a tool doing it?

I currently do:

./sapi/cli/php Zend/bench.php

The result:

https://gist.github.com/4bbc33b7b5dcedc6bd66



On Fri, Oct 23, 2015 at 12:39 AM, Dmitry Stogov <dmi...@zend.com> wrote:

>
> On Oct 22, 2015 3:45 PM, "Lin Yo-An" <cornelius.h...@gmail.com> wrote:
> >
> > Hi all,
> >
> >
> > I am looking into zend op_array structure, and few questions raised in
> my mind:
> >
> > 1. Why op_array->refcount uses *uint32 instead of uint32, is there a
> reason? if we can replace it with uint32, then we might save one emalloc
> call for memory allocation for every op_array allocation?
>
> We may have few different op_array structures with the same opcodes but
> with different names for example. So just uint32won't work.
>
> >
> > 2. There are also a lot of information saved in the op_array structure,
> if we can move line_start, line_end, doc_comments...etc into an external
> structure, then we might be able to reduce the op_array size and decrease
> the cache miss? is it doable?
>
> I'm not sure if patritioning data of op_array, into frequntly and rarely
> used, may make any significant difference. Because we usually work only
> with a single instance of op_array in each moment. Fields reordering alrecy
> helped to reduce cache-misses. But I may be wrog :)
>
> Thanks. Dmitry.
>
> >
> >
> >
> > Cheers,
> > Yo-An Lin
> > https://github.com/c9s
> >
>



-- 
Best Regards,

Yo-An Lin

[PHP-DEV] few questions about op_array

[Lin Yo-An]

Hi all,


I am looking into zend op_array structure, and few questions raised in my
mind:

1. Why op_array->refcount uses *uint32 instead of uint32, is there a
reason? if we can replace it with uint32, then we might save one emalloc
call for memory allocation for every op_array allocation?

2. There are also a lot of information saved in the op_array structure, if
we can move line_start, line_end, doc_comments...etc into an external
structure, then we might be able to reduce the op_array size and decrease
the cache miss? is it doable?



Cheers,
Yo-An Lin
https://github.com/c9s