On Fri, 16 Jul 2004, Andi Gutmans wrote:
> Part of the changes I want to do for PHP 5.1 is integrating some of the
> ideas from your patch and ideas I had in the past. The first one I want to
> integrated is the opcode-threading which will come shortly.
I'd also be very interested in backporting
On Fri, 16 Jul 2004, Thies C. Arntzen wrote:
> after your patch: 13,63 sec
> before your patch : 11,86 sec
I'd say that's an unacceptable performance drop ;-)
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
At 07:08 PM 7/16/2004 +0200, Thies C. Arntzen wrote:
On Fri, 16 Jul 2004 09:32:10 -0700, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Do you have the source?
> I think it'd be more interesting to see the performance difference on a
> real world application such as phpBB, phpnuke or similar. If you can
On Fri, 16 Jul 2004 09:32:10 -0700, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Do you have the source?
> I think it'd be more interesting to see the performance difference on a
> real world application such as phpBB, phpnuke or similar. If you can give
> us numbers on that, it would definitely impro
On Fri, 16 Jul 2004 12:46:47 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> On July 16, 2004 12:41 pm, Thies C. Arntzen wrote:
> > php has no real concept for out-of-memory situations (stack or real)
> > - nor do we catch infinite (nor too deep) recursions. allowing for
> > "deeper" recursio
That is nowhere near a real-life application. There's no logic only
function calls.
Look, I asked Ilia not to change the alloca() but eventually agreed. So
personally I have no problem with undoing that patch, but I still think
that not testing real-life applications is not the way to make a cas
On July 16, 2004 12:41 pm, Thies C. Arntzen wrote:
> php has no real concept for out-of-memory situations (stack or real)
> - nor do we catch infinite (nor too deep) recursions. allowing for
> "deeper" recursion doesn't really fix anything. so, i think we should
> either come up with a real soluti
Here you go.
Ilia
On July 16, 2004 12:32 pm, Andi Gutmans wrote:
> Do you have the source?
> I think it'd be more interesting to see the performance difference on a
> real world application such as phpBB, phpnuke or similar. If you can give
> us numbers on that, it would definitely improve your
On Fri, 16 Jul 2004 12:15:46 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> On July 16, 2004 11:58 am, Thies C. Arntzen wrote:
> > hey ilia,
> >
> > here's another one of my meaningess, synthetic benchmarks (this is how
> > the CreatorsOfPHP(tm) would call them)
> >
> > ackermann(8) (source o
can we put that in the release notes - "php is like 50% more stable,
it takes 20 seconds not 10 to crash it?"
-sterling
On Fri, 16 Jul 2004 12:15:46 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> On July 16, 2004 11:58 am, Thies C. Arntzen wrote:
> > hey ilia,
> >
> > here's another one of
Do you have the source?
I think it'd be more interesting to see the performance difference on a
real world application such as phpBB, phpnuke or similar. If you can give
us numbers on that, it would definitely improve your point if the
performance penalty show in that case.
At 05:58 PM 7/16/200
On July 16, 2004 11:58 am, Thies C. Arntzen wrote:
> hey ilia,
>
> here's another one of my meaningess, synthetic benchmarks (this is how
> the CreatorsOfPHP(tm) would call them)
>
> ackermann(8) (source on request - highly recursive)
Recursive functions in PHP are inherently dangerous as without
On Fri, 16 Jul 2004 08:39:21 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> Oops mail client assign the message to the wrong patch.
> In response to Andi's question, we can probably get away with using a regular
> malloc since the number of variables needed to cause a crash will probably
> ca
On Jul 16, 2004, at 3:22 AM, Thies C. Arntzen wrote:
this will have a performance impact on every function call in php. and
it won't stop fix out-of-memory crashes completely.
i really don't think this is what we should do...
Well, allocating it all in stack memory seems intractable - you can
easi
Marcus,
Please revert this patch! You can close the bug as bogus. There is no
reason this should work and we're not going to check strings at run-time to
see if they look like a static function.
If there's a problem with foo::$bar() not working and having worked before
then that's a different m
> class foo{function bar(){print "bar\n";} } $a="bar"; foo::$a();
>
> does not work since earlier php5 releases, already well known afair (and
> really annoyed ;) ).
If parameterized method names don't work anymore, will
call_user_func_array() be able to return a reference? IIRC, it didn't
with
Hello Andrei,
Tuesday, January 6, 2004, 1:06:05 AM, you wrote:
> On Tue, 06 Jan 2004, Marcus Boerger wrote:
>> > Is 'class::method' syntax supported by call_user_function() as well
>> > then?
>>
>> No but for that you have call_user_method() or the preferred way of using
>> the array notation. W
On Tue, 06 Jan 2004, Marcus Boerger wrote:
> > Is 'class::method' syntax supported by call_user_function() as well
> > then?
>
> No but for that you have call_user_method() or the preferred way of using
> the array notation. When i made the patch that allowed static calls from
> within sqlite i di
On Tue, 6 Jan 2004, Pierre-Alain Joye wrote:
> class foo{function bar(){print "bar\n";} } $a="bar"; foo::$a();
>
> does not work since earlier php5 releases, already well known afair (and
> really annoyed ;) ).
Yes. I forgot to put that in my bug report. That was how I originally
tried to invoke
Hello Andrei,
Tuesday, January 6, 2004, 12:34:45 AM, you wrote:
> On Tue, 06 Jan 2004, Marcus Boerger wrote:
>> > On Tue, 06 Jan 2004, Marcus Boerger wrote:
>> >> I see "\$obj->blah" much different becasue it would require evaluating the
>> >> string and access the current symbol table to get $ob
On Tue, 6 Jan 2004 00:32:56 +0100
Marcus Boerger <[EMAIL PROTECTED]> wrote:
> I only changed the what can be done with single variables. And there i
> added the ability to call static methods like you can do from sqlite's
> sql. Please show me an example that does work in 4 but not in 5 if i
> mis
On Tue, 06 Jan 2004, Marcus Boerger wrote:
> > On Tue, 06 Jan 2004, Marcus Boerger wrote:
> >> I see "\$obj->blah" much different becasue it would require evaluating the
> >> string and access the current symbol table to get $obj. Further more we'd
> >> need to patch $this and so on. On the other h
Hello Andrei,
Tuesday, January 6, 2004, 12:26:38 AM, you wrote:
> On Tue, 06 Jan 2004, Marcus Boerger wrote:
>> I see "\$obj->blah" much different becasue it would require evaluating the
>> string and access the current symbol table to get $obj. Further more we'd
>> need to patch $this and so on.
On Tue, 06 Jan 2004, Marcus Boerger wrote:
> I see "\$obj->blah" much different becasue it would require evaluating the
> string and access the current symbol table to get $obj. Further more we'd
> need to patch $this and so on. On the other hand $class::$method() should
> access the static propert
Hello Andrei,
Tuesday, January 6, 2004, 12:07:35 AM, you wrote:
> On Mon, 05 Jan 2004, Marcus Boerger wrote:
>> hellyMon Jan 5 17:45:12 2004 EDT
>>
>> Modified files:
>> /ZendEngine2 zend_execute.c
>> /ZendEngine2/tests bug26802.phpt
>> Log:
On Mon, 05 Jan 2004, Marcus Boerger wrote:
> helly Mon Jan 5 17:45:12 2004 EDT
>
> Modified files:
> /ZendEngine2 zend_execute.c
> /ZendEngine2/testsbug26802.phpt
> Log:
> Fixed bug #26802
I think a better approach is to follow the $class::$meth
On 2003/12/05, at 17:38, Sascha Schumann wrote:
I've tried to do so again and again for last two or three hours, but
I'm stuck with some CVS weirdness now. Anyone...?
The stale locks have been purged.
Thanks.
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, v
On Fri, 5 Dec 2003, Moriyoshi Koizumi wrote:
>
> On 2003/12/05, at 5:37, Ilia Alshanetsky wrote:
>
> > On December 4, 2003 12:38 pm, Moriyoshi Koizumi wrote:
> >> moriyoshi Thu Dec 4 12:38:21 2003 EDT
> >>
> >> Modified files:
> >> /ZendEngine2 zend_execute.c
> >> Log:
> >> R
On 2003/12/05, at 5:37, Ilia Alshanetsky wrote:
On December 4, 2003 12:38 pm, Moriyoshi Koizumi wrote:
moriyoshi Thu Dec 4 12:38:21 2003 EDT
Modified files:
/ZendEngine2zend_execute.c
Log:
Revert crap.
Please don't forget to revert the ZE1 patch.
I've tried to do so again and
Stanislav Malyshev wrote:
> stas Thu Mar 27 12:57:48 2003 EDT
>
> Modified files:
> /ZendEngine2 zend_execute.c
> Log:
> fix fetch_class buglet
That did the trick.
Thank you,
Sebastian
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://php
Stanislav Malyshev wrote:
> Also refine namespaced includes
This seems not to work the way I expected:
TestCase.php
1
FooTest.php
1
CLI.php
1
E:\>php cli.php
Fatal error: Class 'footest' not found in E:\cli.php on line 6
--
Sebastian Bergmann
http://s
31 matches
Mail list logo
