Patch for opcode caches

17 years ago by Dmitry Stogov — view source — reply

unread

-----Original Message-----
From: Marcus Boerger [mailto:helly@php.net]
Sent: Friday, March 14, 2008 8:24 PM
To: Stas Malyshev
Cc: Dmitry Stogov; Andi Gutmans; phpxcache; internals@lists.php.net
Subject: Re: [PHP-DEV] Patch for opcode caches

Hello Stanislav,

Friday, March 14, 2008, 5:51:49 PM, you wrote:

But that means we are compiling inheritance when a file is loaded
form the cache. The goal should be to compiling inheritance when
writing to the opcode cache file. All we achieve here is a
slow down.
If there is

You can not do that. You do not know that until runtime.

something that makes this required than at least we need
to warn the
user about the slow code. I Think what we need to do is
deprecating
class and

It won't be slow. It would be much faster (in some cases
10x faster).
This specific assembly of instructions might be slower in
some cases,
but the code altogether will be faster. That's the idea of
the opcode
caches.

namespace use in non main blocks as well as include and require in
non main blocks. And if there is no such case than
everything can be
bound early which is the fast state we should aim for.

Lemme just think, doing inheritance at compile time before we
send the stuff to an opcode cache can be slower then?

It's always faster, but with opcode caches we cannot always do it in
compile-time, because the parent (in another file) might be changed on
next load of children class.

How is
that possible? After all late binding means we do it at run
time. And no matter how much faster we can do it. It will
always be slower than doing the same thing only once.

We do not need to deprecate anything, and inheritance can
not be bound
before parent class is known, which in the case of bytecode
cache means

not before the file is loaded from the cache. That's
exactly what this
patch enables. It does not change performance
characteristics of neither
cached not non-cached code, it just makes it much simpler
and working in
all cases.

Inheritance cannot be done before the parent class is known.
We still need to do the prototype checks even if we assume
the class is there and insert a virtual class as parent somehow.

Right. This is the reason why we need to delay early binding. But we
don't like to delay it to run-time, because it will breake the class
creaton order and as result may breake some scripts.

Thanks. Dmitry.

17 years ago by Marcus Boerger — view source — reply

unread

Hello Dmitry,

can you please fix your mail client? You are breaking every single thread
you reply to. Thx!

marcus

Monday, March 17, 2008, 9:07:41 AM, you wrote:

-----Original Message-----
From: Marcus Boerger [mailto:helly@php.net]
Sent: Friday, March 14, 2008 8:24 PM
To: Stas Malyshev
Cc: Dmitry Stogov; Andi Gutmans; phpxcache; internals@lists.php.net
Subject: Re: [PHP-DEV] Patch for opcode caches

Hello Stanislav,

Friday, March 14, 2008, 5:51:49 PM, you wrote:

But that means we are compiling inheritance when a file is loaded
form the cache. The goal should be to compiling inheritance when
writing to the opcode cache file. All we achieve here is a
slow down.
If there is

You can not do that. You do not know that until runtime.

something that makes this required than at least we need
to warn the
user about the slow code. I Think what we need to do is
deprecating
class and

It won't be slow. It would be much faster (in some cases
10x faster).
This specific assembly of instructions might be slower in
some cases,
but the code altogether will be faster. That's the idea of
the opcode
caches.

namespace use in non main blocks as well as include and require in
non main blocks. And if there is no such case than
everything can be
bound early which is the fast state we should aim for.

Lemme just think, doing inheritance at compile time before we
send the stuff to an opcode cache can be slower then?

It's always faster, but with opcode caches we cannot always do it in
compile-time, because the parent (in another file) might be changed on
next load of children class.

How is
that possible? After all late binding means we do it at run
time. And no matter how much faster we can do it. It will
always be slower than doing the same thing only once.

We do not need to deprecate anything, and inheritance can
not be bound
before parent class is known, which in the case of bytecode
cache means

not before the file is loaded from the cache. That's
exactly what this
patch enables. It does not change performance
characteristics of neither
cached not non-cached code, it just makes it much simpler
and working in
all cases.

Inheritance cannot be done before the parent class is known.
We still need to do the prototype checks even if we assume
the class is there and insert a virtual class as parent somehow.

Right. This is the reason why we need to delay early binding. But we
don't like to delay it to run-time, because it will breake the class
creaton order and as result may breake some scripts.

Thanks. Dmitry.

Best regards,
Marcus

17 years ago by Dmitry Stogov — view source — reply

unread

I hope it must be fixed now.

Dmitry.

Marcus Boerger wrote:

Hello Dmitry,

can you please fix your mail client? You are breaking every single thread
you reply to. Thx!

marcus

Monday, March 17, 2008, 9:07:41 AM, you wrote:

-----Original Message-----
From: Marcus Boerger [mailto:helly@php.net]
Sent: Friday, March 14, 2008 8:24 PM
To: Stas Malyshev
Cc: Dmitry Stogov; Andi Gutmans; phpxcache; internals@lists.php.net
Subject: Re: [PHP-DEV] Patch for opcode caches

Hello Stanislav,

Friday, March 14, 2008, 5:51:49 PM, you wrote:

But that means we are compiling inheritance when a file is loaded
form the cache. The goal should be to compiling inheritance when
writing to the opcode cache file. All we achieve here is a
slow down.
If there is
You can not do that. You do not know that until runtime.
something that makes this required than at least we need
to warn the
user about the slow code. I Think what we need to do is
deprecating
class and
It won't be slow. It would be much faster (in some cases
10x faster).
This specific assembly of instructions might be slower in
some cases,
but the code altogether will be faster. That's the idea of
the opcode
caches.
namespace use in non main blocks as well as include and require in
non main blocks. And if there is no such case than
everything can be
bound early which is the fast state we should aim for.
Lemme just think, doing inheritance at compile time before we
send the stuff to an opcode cache can be slower then?

It's always faster, but with opcode caches we cannot always do it in
compile-time, because the parent (in another file) might be changed on
next load of children class.

How is
that possible? After all late binding means we do it at run
time. And no matter how much faster we can do it. It will
always be slower than doing the same thing only once.

We do not need to deprecate anything, and inheritance can
not be bound
before parent class is known, which in the case of bytecode
cache means

not before the file is loaded from the cache. That's
exactly what this
patch enables. It does not change performance
characteristics of neither
cached not non-cached code, it just makes it much simpler
and working in
all cases.
Inheritance cannot be done before the parent class is known.
We still need to do the prototype checks even if we assume
the class is there and insert a virtual class as parent somehow.

Right. This is the reason why we need to delay early binding. But we
don't like to delay it to run-time, because it will breake the class
creaton order and as result may breake some scripts.

Thanks. Dmitry.

Best regards,
Marcus