[PHP-DEV] few questions about op_array

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

Re: [PHP-DEV] few questions about op_array

, Dmitry Stogov wrote: > > On Oct 22, 2015 3:45 PM, "Lin Yo-An" 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

Re: [PHP-DEV] few questions about op_array

Hi Hui, On Fri, Oct 23, 2015 at 8:27 PM, Xinchen Hui wrote: > Hey Lin: > > On Fri, Oct 23, 2015 at 3:31 PM, Lin Yo-An > wrote: > >> Hi Dmitry, >> >> >> I changed and tested it, and it looks like it gains some improvements. >> how do you compare t

Re: [PHP-DEV] Object getter method optimization

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

[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

[PHP-DEV] Re: Object getter method optimization

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

Re: [PHP-DEV] Object getter method optimization

gt; 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 ad

Re: [PHP-DEV] Object getter method optimization

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 wrote: >

Re: [PHP-DEV] Object getter method optimization

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 wrote: > Hi internals, > > > Here comes the result: > > Without getter optimization (3 runs): > > 250.76603889465ms > > With getter optimization

[PHP-DEV] Re: Object getter method optimization

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, Nikit

[PHP-DEV] Re: Object getter method optimization

/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 meth

[PHP-DEV] Re: Object getter method optimization

t; 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. > > > -

[PHP-DEV] Re: Object getter method optimization

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

[PHP-DEV] Re: Object getter method optimization

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

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 c

[PHP-DEV] Re: Object getter method optimization

Yeah I know. I've saw that yesterday.

Re: [PHP-DEV] Final properties

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

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 w

[PHP-DEV] Re: Object getter method optimization

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

[PHP-DEV] Re: Object getter method optimization

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 wh

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

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 wit

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

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

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

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);

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

Derick Rethans 於 2016年4月14日 星期四寫道： > On Thu, 14 Apr 2016, Lin Yo-An wrote: > > > On Thu, Apr 14, 2016 at 5:12 PM, Derick Rethans > wrote: > > I think type conversion shouldn't be done internally, implicitly. > > > > Implicit conversion leads more confus

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

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.

[PHP-DEV] optimization for function call without paremters

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 i

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

at 5:27 PM, Lin Yo-An 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'

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

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

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

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] Re: Improving PHP's type system

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

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 un

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

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

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

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

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

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 pr

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

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] Proposal: Startup snapshot for optimizing app load time

On Tue, Apr 19, 2016 at 3:10 AM, François Laupretre wrote: > > Le 13/04/2016 17:55, Lin Yo-An a écrit : > You are mixing 2 related mechanisms here : code persistence and data > persistence. > > Code persistence (reloading the same code again and again in each request) > is

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

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