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, Z
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):
> > http://marc.info/?l=php-internals&m=12175
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-internals&m=121750618525882&w=2
There's also a thing that now code like:
$var = 3/0;
(of course, it could be more complex - b
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
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"
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.
>
> Tha
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 optimizat
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
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 consta
Hi Matt,
Now I know. :)
Anyway, I don't think this optimization will work often.
Send me the patch after Alpha1 release.
Thanks. Dmitry.
Matt Wilmas wrote:
> Hi Dmitry,
>
> Do you know that with your changes, no substitution will happen in a
> namespace even when using :: prefix? :-/ (That's
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
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 c
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 sometimes, and sometimes not (if in a namespace or
ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION is set). I changed things so that
there is no subst
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
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 w
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 constants,
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 an
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: Thur
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 TRUE/
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. Howeve
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 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.
http://realplain.com/php/con
22 matches
Mail list logo
