Hi Matt,
I updated your patch a little bit to make it more clear (from my point
of view).
Please take a look.
Thanks. Dmitry.
Matt Wilmas wrote:
Hi Dmitry,
Well, it's been awhile since Alpha 1 :-), so I wanted to finally resend this
before Alpha 2! I agree that the additional optimization
Hi Dmitry,
Yeah, that looks good too, and should work the same way. :-)
Thanks,
Matt
- Original Message -
From: Dmitry Stogov
Sent: Friday, August 29, 2008
Hi Matt,
I updated your patch a little bit to make it more clear (from my point
of view).
Please take a look.
Thanks.
Ok, I'm going to commit it.
Could you remember why we disabled constants substitution for ZEND_CT?
Thanks. Dmitry.
Matt Wilmas wrote:
Hi Dmitry,
Yeah, that looks good too, and should work the same way. :-)
Thanks,
Matt
- Original Message -
From: Dmitry Stogov
Sent:
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent: Friday, August 29, 2008
Ok, I'm going to commit it.
Could you remember why we disabled constants substitution for ZEND_CT?
Yeah, it's to make sure something like -CONST in ZEND_CT context doesn't
work sometimes, sometimes
Hi!
Yeah, it's to make sure something like -CONST in ZEND_CT context doesn't
work sometimes, sometimes not. My previous message (first part):
http://marc.info/?l=php-internalsm=121750618525882w=2
There's also a thing that now code like:
$var = 3/0;
(of course, it could be more complex -
Hi Stas,
- Original Message -
From: Stanislav Malyshev
Sent: Friday, August 29, 2008
Hi!
Yeah, it's to make sure something like -CONST in ZEND_CT context
doesn't
work sometimes, sometimes not. My previous message (first part):
Hi!
I'm not sure what you mean, does not compile? Nothing has been changed that
should affect any code like your example...
Oh, I think I was confusing two constant patches - I was thinking about
the constant evaluation patch, not constant fetching patch. Sorry.
--
Stanislav Malyshev, Zend
Hi Dmitry,
Well, it's been awhile since Alpha 1 :-), so I wanted to finally resend this
before Alpha 2! I agree that the additional optimization probably wouldn't
happen often, as there won't be that much namespace usage right away, I
assume. But I think it makes sense to handle :: prefix
On 28.08.2008, at 16:18, Matt Wilmas wrote:
Well, it's been awhile since Alpha 1 :-), so I wanted to finally
resend this
before Alpha 2! I agree that the additional optimization probably
wouldn't
happen often, as there won't be that much namespace usage right
away, I
assume. But I think
Thanks Matt. I committed near the same patch.
It's not so optimal, but little bit more clear.
Thanks. Dmitry.
Matt Wilmas wrote:
Hi Dmitry,
For the behavior change that I mentioned in the other thread, with this
code:
function foo() {
static $a = -PHP_INT_MAX;
}
Which could work
Hi Dmitry,
Do you know that with your changes, no substitution will happen in a
namespace even when using :: prefix? :-/ (That's what I would do when I
know it's global, for optimization.) Or is that what you meant by not so
optimal?
- Matt
- Original Message -
From: Dmitry Stogov
Hi Dmitry,
I saw that you commited this patch, with the addition of only replacing
persistent constants (just mentioning for others on the list). The attached
patches have a few tweaks:
The main thing I noticed is that if something creates a persistent,
case-INsensitive constant (any of those
Hi Matt,
Sorry if I missed it.
Does this patch make any performance difference?
I assume it saves on hash lookup during compilation and its really
insignificant time. However it add new scanner rules which may slowdown
the whole scanner.
For now I don't see a big reason, but may be I didn't
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent: Thursday, July 24, 2008
Hi Matt,
Sorry if I missed it.
No problem. :-)
Does this patch make any performance difference?
I assume it saves on hash lookup during compilation and its really
insignificant time. However it add
According to constants patch, it definitely will break PHP encoders and
may be opcode caches, but as you mentioned the compiler_option will
solve the issue. In this case we probable may substitute any constants
(not only persistent). Anyway I don't see a big reason for special
handling of
I would propose the attached patch for this optimization.
Opcode caches and encoders will have to disable this optimization with
ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION
Any objections?
Thanks. Dmitry.
Matt Wilmas wrote:
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent:
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent: Thursday, July 24, 2008
According to constants patch, it definitely will break PHP encoders and
may be opcode caches, but as you mentioned the compiler_option will
solve the issue. In this case we probable may substitute any
Hi again Dmitry,
Well, that should get the main runtime optimization job done just as well.
:-) I was just trying for more compile-time improvement also (it was
definitely measurable with fake tests), especially for those not using an
opcode cache, with no lookup needed for the 3 basic
Thank you for noticing SID issue.
So it seems like we able to substitute only persistent constants.
Thanks. Dmitry.
Matt Wilmas wrote:
Hi again Dmitry,
Well, that should get the main runtime optimization job done just as well.
:-) I was just trying for more compile-time improvement also (it
Hi all,
Never heard anything about this optimization after sending it 3 months ago
(should've sent a follow-up sooner)...
Is this something that can be done? Dmitry? Details in original message.
Patch is unchanged, I just updated them for the current file versions.
Hi all,
I changed things so that the many built-in constants (CONST_PERSISTENT
ones) will be replaced at compile-time, saving the FETCH_CONSTANT opcode, if
these changes are usable. This was added for TRUE/FALSE/NULL 2 years ago,
but seems like it can be done for lots of others too.
Since the
21 matches
Mail list logo
