On 04.12.2007 06:00, Cristian Rodriguez wrote:
such switches only add more complexity, confusion for users and
addtional trouble to distributors.
... which I believe are going to enable this flag by default anyway,
because they don't care about performance too much.
So I agree, either do it
On Mon, 3 Dec 2007, Brian Shire wrote:
On Dec 3, 2007, at 2:17 PM, Stanislav Malyshev wrote:
I am a developer on a CMS also which uses the auto-include
functionality to include many classes over many files. Each
request can include up to 30 different files. The speed increase
I think I understand what the use-case is…
If the browser doesn't know anything about script tag, it is
supposed to interpret it's contents as html… In which case, html-tags
which appear in javascript code will actually become active ones
The common practice for dealing with this problem is
I believe this has to be done and it should be always on.
Having less headache is good. I will find other ways to speed up my projects
On 12/4/07, Antony Dovgal [EMAIL PROTECTED] wrote:
On 04.12.2007 06:00, Cristian Rodriguez wrote:
such switches only add more complexity, confusion for users
Hi everyone,
i just want to throw in my 2 cents. I've experimented alot with file
bundling in the past on several projects and i can confirm that is
does have a positive affect in applications that include/require a lot
of files during a request (at least thats how it looks like!). Yes my
On Tue, 2007-12-04 at 00:00 -0300, Cristian Rodriguez wrote:
2007/12/3, Ilia Alshanetsky [EMAIL PROTECTED]:
I think the patch does have a value,
yes, it does, what worries me is the introduction of yet another
non-sense ini setting that modified the very engine behaviuor.. I
think we all
I raised bug http://bugs.php.net/bug.php?id=43480 noting that the behaviour
of the array functions next, current, prev had been changed in 5.3.
Previously (5.2 and before) it was possible to use these as a crude iterator
over object properties. In 5.3 this behaviour has been removed.
The bug has
the only documented way to iterate over properties is using foreach
http://www.php.net/manual/en/language.oop5.iterations.php
Does that one still work?
On 12/4/07, robert nicholson [EMAIL PROTECTED] wrote:
I raised bug http://bugs.php.net/bug.php?id=43480 noting that the behaviour
of the
I could be wrong, of course, but my guess is that the ~3% speed decrease
a) is not really significant to 95% of the users (I mean _really_
significant; of course, everyone is going to whine about it first) and
b) is going to be eliminated over time
david
Am 04.12.2007 um 03:43 schrieb
Hi,
Are there any tools you can recommend me for debugging my error?
Standard gdb debugging doesn't seem to help, and using valgrind in a
real-time webserver environment simply doesn't work on my device (or on
anyone's device I guess.. :) ).
Thanks, Nir.
-Original Message-
From: Antony
On 04.12.2007 17:07, Rachmel, Nir (Nir) wrote:
Hi,
Are there any tools you can recommend me for debugging my error?
Standard gdb debugging doesn't seem to help, and using valgrind in a
real-time webserver environment simply doesn't work on my device (or on
anyone's device I guess.. :) ).
You may be right longer term but shorter term I still believe there may be
stability issues with this patch some of which we haven't figured out. Although
we did testing and found crash bugs I wouldn't trust our level of testing to
deem it stable. If we go down the route of always on we could
On 04.12.2007 18:31, Andi Gutmans wrote:
You may be right longer term but shorter term I still believe there may be
stability issues with this patch some of which we haven't figured out.
Although we did testing and found crash bugs I wouldn't trust our level of
testing to deem it stable. If
Sorry to step in uninvited to this discussion, I have some doubts about all
this, and I'll really appreciate if someone more knowledgeable could
enlighten my ignorance. The doubts I have are as follows:
1) Why is performance relevant to whether namespaces are implemented one per
file or many per
Brian Shire wrote:
Hi Greg,
I'm sorry that my message probably did come off as condescending. :-(
I really just wanted to share some my *own* pitfalls in case it was
something that might be helpful here.
If you aren't too put off and you are running APC then perhaps we can
discuss more
Roman Borschel wrote:
A small addition:
the exact same test results in the following average times on my dev
machine:
with bundled classes: ~0.07s (~2-10 includes)
without: ~0.10s (~60-80 includes)
Thats ~30ms difference in average. I wanted to post that because the
results on my dev
On Dec 4, 2007, at 5:14 PM, Gregory Beaver wrote:
On the other hand, combining multiple files into a single file results
in line numbers no longer corresponding to the original line numbers
of
the file, adding another translation step when debugging a problem.
Of
course, this is just
Martin Alterisio wrote:
Sorry to step in uninvited to this discussion, I have some doubts about all
this, and I'll really appreciate if someone more knowledgeable could
enlighten my ignorance. The doubts I have are as follows:
1) Why is performance relevant to whether namespaces are
Begin forwarded message:
From: Roman Borschel [EMAIL PROTECTED]
Date: December 4, 2007 5:19:54 PM GMT+01:00
To: Martin Alterisio [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] ignored patches
On Dec 4, 2007, at 5:09 PM, Martin Alterisio wrote:
Sorry to step in uninvited to this discussion, I have
2007/12/4, Roman Borschel [EMAIL PROTECTED]:
On Dec 4, 2007, at 5:09 PM, Martin Alterisio wrote:
1) Why is performance relevant to whether namespaces are implemented
one per
file or many per file?
Because including/requiring 80 files one by one seems to be
significantly slower than
2007/12/4, Gregory Beaver [EMAIL PROTECTED]:
Martin Alterisio wrote:
1) Why is performance relevant to whether namespaces are implemented one
per
file or many per file?
Because there is a performance difference between code in separate files
and the same code in a single file.
[snip]
vserver. And the xdebug profiling result shows me in fact that this
additional time seems to be spend in the autoload facility and its
require_once calls.
OFF: require_once in autoload is not logical to me.
Best Regards,
Felhő
--
PHP Internals - PHP Runtime Development Mailing List
To
On Dec 4, 2007, at 5:50 PM, Martin Alterisio wrote:
2007/12/4, Roman Borschel [EMAIL PROTECTED]:
On Dec 4, 2007, at 5:09 PM, Martin Alterisio wrote:
1) Why is performance relevant to whether namespaces are implemented
one per
file or many per file?
Because including/requiring 80 files one
Martin Alterisio wrote:
I didn't understand. Do you mean that I was wrong? Or that I was right about
namespaces purpose, but that's only needed in development? Therefore,
shouldn't the bundling process remove the need for namespaces (i.e. the
bundling process removes namespaces)?
You can't
Martin Alterisio wrote:
2007/12/4, Gregory Beaver [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Martin Alterisio wrote:
1) Why is performance relevant to whether namespaces are
implemented one per
file or many per file?
Because there is a performance difference between
Yes, thanks i already changed that. Doesnt make a big difference though.
Roman
On Dec 4, 2007, at 6:10 PM, Gergely Hodicska wrote:
vserver. And the xdebug profiling result shows me in fact that this
additional time seems to be spend in the autoload facility and its
require_once calls.
On Dec 4, 2007, at 6:00 PM, Martin Alterisio wrote:
2) I was under the impression namespaces were introduced to improve
code
maintainability. Was I wrong?
You are right. On the flip side, if you can't use your maintainable
code because it is slow as molasses, that is a problem.
If
your head). Can you please be more responsible and provide some real
results ?
Results of what?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To
You are putting forward some hypothetical results. I want to know, for the
benefit of the discussion, if you can prove the 5% figure you've advanced.
On Dec 4, 2007 12:36 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
your head). Can you please be more responsible and provide some real
no APC, with APC, and with APC and apc.stat=0. The benchmark in
question compared require_once to include with full paths to a single
file. In the best case, I got a 12% performance difference between
include with full paths and apc.stat=0 and a single file.
12% sounds more realistic than
You are putting forward some hypothetical results. I want to know, for
No I am not.
the benefit of the discussion, if you can prove the 5% figure you've
advanced.
There's nothing to prove - I want to see the measure of improvement
bundling provides on real-life applications. So far I have
Hi all,
It has nothing to do with little peon.
Be fair Stas, Brian already apologized for the way that post came across.
You argue that we need some language-level change to improve performance
(and it is the only reason to add it). It is suspected that this language
change has very high
I think I understand what the use-case is…
If the browser doesn't know anything about script tag, it is
supposed to interpret it's contents as html… In which case, html-tags
which appear in javascript code will actually become active ones
This makes sense. Though wouldn't
Couldn't there be some way to mark a 'bundle' file and use that mark to
discriminate between where multiple namespaces are or are not allowed in
zend_compile.c? That would eliminate the potential for abuse, no?
Not really. People would start bundling files left and right, just
because
Hi,
There's been enough confusion, here's the patch again, this time against
5.3, no tests for clarity
http://pear.php.net/~greg/multi.5.3.patch.txt
This patch allows:
?php
namespace A;
class a {}
namespace B;
class a {}
namespace A;
import B::a as b;
class c extends b;
?
It doesn't allow:
2007/12/4, Gregory Beaver [EMAIL PROTECTED]:
Martin Alterisio wrote:
2007/12/4, Gregory Beaver [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Martin Alterisio wrote:
1) Why is performance relevant to whether namespaces are
implemented one per
file or many per file?
The need to pack a program all into a single source file for performance
reasons would seem to indicate that the way PHP compiles/interprets
could be improved. Wouldn't it be better to improve this area than add
language features to deal with the issue?
--
Michael McGlothlin
Southwest
Couldn't there be some way to mark a 'bundle' file and use that mark to
discriminate between where multiple namespaces are or are not allowed in
zend_compile.c? That would eliminate the potential for abuse, no?
Not really. People would start bundling files left and right, just
because
The need to pack a program all into a single source file for performance
reasons would seem to indicate that the way PHP compiles/interprets could
be improved. Wouldn't it be better to improve this area than add language
features to deal with the issue?
How do you improve the performance of a
that could see some real benefits from this code. My suggestion is that
we make this feature a compile time flag, that's off by default and
What about binary compatibility?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL
I could be wrong, of course, but my guess is that the ~3% speed decrease
a) is not really significant to 95% of the users (I mean _really_
significant; of course, everyone is going to whine about it first) and
GC is not really useful to 95% of the users either, so is 5% of the
users important
Previously (5.2 and before) it was possible to use these as a crude iterator
over object properties. In 5.3 this behaviour has been removed.
It would be nice if these functions would work with any Iterator
implementation.
As for regular objects, what would be the reason not to keep it as it
2007/12/4, Michael McGlothlin [EMAIL PROTECTED]:
The need to pack a program all into a single source file for performance
reasons would seem to indicate that the way PHP compiles/interprets
could be improved. Wouldn't it be better to improve this area than add
language features to deal with
That depends on how many 'bundle files' are allowed. I hate to say it, but
if this were an INI directive rather than a keyword it would be possible
to limit bundling to a single file, or to any given number.
Take that back, it wouldn't work... I was thinking of single applications
rather than
The need to pack a program all into a single source file for
performance reasons would seem to indicate that the way PHP
compiles/interprets could be improved. Wouldn't it be better to
improve this area than add language features to deal with the issue?
How do you improve the performance of a
On Tue, 2007-12-04 at 10:43 -0800, Stanislav Malyshev wrote:
Previously (5.2 and before) it was possible to use these as a crude iterator
over object properties. In 5.3 this behaviour has been removed.
It would be nice if these functions would work with any Iterator
implementation.
As
I strongly suspect performance difference in bundles does not follow
from syscalls. On include() PHP does a lot more than just issue a couple
of syscalls.
So Michael's right and it needs some proper investigation.
- Steph
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]
Martin Alterisio wrote:
It's also not possible to reliably bundle files even if you could have
multiple namespaces declarations as, correct me if I'm wrong, import
statements affect the whole file, there is no way to unimport, a
name clash could still occur.
OK, I'll correct you: you're
2007/12/4, Gregory Beaver [EMAIL PROTECTED]:
Martin Alterisio wrote:
It's also not possible to reliably bundle files even if you could have
multiple namespaces declarations as, correct me if I'm wrong, import
statements affect the whole file, there is no way to unimport, a
name clash
Antony Dovgal wrote:
On 04.12.2007 18:31, Andi Gutmans wrote:
You may be right longer term but shorter term I still believe there may be
stability issues with this patch some of which we haven't figured out.
Although we did testing and found crash bugs I wouldn't trust our level of
testing
Actually, it's an expected tradeoff of interpreted languages.
Compilable languages have both a compiler and a linker that bundles
everything in one executable. By using bytecode caching and bundling
you're just getting closer to the performance expectations of a
compilable language. But
I think having it configurable is a must. Turning it on / off via a compile
flag will not suit everyone.
Eg - I have a situation where I would not want to run garbage collection for
web pages served off my server due to the performance hit, however I also have
a CLI script which I run to do
2007/12/4, Michael McGlothlin [EMAIL PROTECTED]:
Actually, it's an expected tradeoff of interpreted languages.
Compilable languages have both a compiler and a linker that bundles
everything in one executable. By using bytecode caching and bundling
you're just getting closer to the
Quoting Martin Alterisio [EMAIL PROTECTED]:
Knowing that I'll have to strongly encourage the developers to dump that
patch. The namespace declaration shouldn't do more than what it's expected
to do. Why this:
namespace yadayada;
import yadayada;
Should work different that:
import yadayada;
I want to put my 2 cents, but before make any comment, I'm interested
to know if it's only a performance impact.
Talking about performance is ok and I agree that any penalty should be
taken into account, but if the patch uses less memory resources, I
think that shared hostings will care about it.
[EMAIL PROTECTED] wrote:
I think having it configurable is a must. Turning it on / off via a compile
flag will not suit everyone.
Looking at the code, that isn't really possible. You could have a
switch to turn off the collection, but that won't get you your
performance back. To avoid the
I'm a firm believer that it's better to throw more CPU power at a
performance problem than to make code less maintainable. Just buy a faster
server.
That hardly applies to library developers, though. They don't have control
over their users' CPU power...
- Steph
--
PHP Internals - PHP
1. Always compile it in but leave undocumented #ifdefs in place for
performance freaks. Those same performance freaks aren't going to care
about the binary compatibility issue since they are the same people who
build all their own stuff.
Note that breaking BC is not only about performance -
Stanislav Malyshev wrote:
1. Always compile it in but leave undocumented #ifdefs in place for
performance freaks. Those same performance freaks aren't going to care
about the binary compatibility issue since they are the same people who
build all their own stuff.
Note that breaking BC is
I'm a firm believer that it's better to throw more CPU power at a
performance problem than to make code less maintainable. Just buy a
faster server.
That hardly applies to library developers, though. They don't have
control over their users' CPU power...
You should write the best good you can
I support this patch 100%. I have a large application I'm rewriting to
include namespaces, however now I can no longer use my script caching
functionality (which improved performance literally about 500%) that
compiled all of my includes into one file, because many of the files
have namespaces.
2007/12/4, Chuck Hagenbuch [EMAIL PROTECTED]:
Quoting Martin Alterisio [EMAIL PROTECTED]:
Knowing that I'll have to strongly encourage the developers to dump that
patch. The namespace declaration shouldn't do more than what it's
expected
to do. Why this:
namespace yadayada;
import
Hello,
following some discussions on the list (re. multiple namespaces in file)
as well as a short discussion on IRC regarding not being able to do
use yeti::xml::DomDocument as DomDocument; - I do not see any point in having
namespaces at all. And my excuses for the somewhat longish mail...
I used the following test code:
What do these included file do? Is it part of some real-life
application?
From my previous mail: The files come from a real life project., the
site has almost 80 million hit per day.
DO they do any work besides being included?
No, I put the codes in the files
With all the above considerations, especially my first point, I still have not
heard any good reason why namespaces in the current implementation are actually
useful - or what particular case they solve... so I am wondering, are they
really useful? I come now to the conclusion that they are not,
Martin Alterisio wrote:
2007/12/4, Chuck Hagenbuch [EMAIL PROTECTED]:
Quoting Martin Alterisio [EMAIL PROTECTED]:
Knowing that I'll have to strongly encourage the developers to dump that
patch. The namespace declaration shouldn't do more than what it's
expected
to do. Why this:
namespace
Derick Rethans wrote:
With all the above considerations, especially my first point, I still have not
heard any good reason why namespaces in the current implementation are
actually
useful - or what particular case they solve... so I am wondering, are they
really useful? I come now to the
I used import in my last example instead of use, that was simply a typo,
not trying to open a can of worms.
Sorry,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Dec 4, 2007 5:41 PM, Steph Fox [EMAIL PROTECTED] wrote:
Hi D,
extension (DateTime, DateTimeZone). However introducing the new class
DateTimeSpan might break people's code that do things like:
?php
use myNamespace::DateTimeZone as DateTimeZone;
?
Typo? I guess you meant
following some discussions on the list (re. multiple namespaces in file)
as well as a short discussion on IRC regarding not being able to do
use yeti::xml::DomDocument as DomDocument; - I do not see any point in having
You mean like ability to override existing classes? I think it could be
up a few days ago and again, everyone who says that they get a
performance gain by aggregating the files (Like compiled PHP files)
are being either ignored or in some way insulted... Anyways, some
That's the first time I hear asking somebody to help reproducing his
benchmark is an insult. But
However, in the global scope (no namespace) it would fail. This is a
bug that is easily fixed. use should allow re-aliasing of global
classes, and I could provide a very easy fix.
This is not a bug - since there you work with test::xmlreader, which of
course you can define. But in global
DO they do any work besides being included?
No, I put the codes in the files inside an if (0), I wanted to test only
the include.
Yes, that's my point - 3X faster include opcode is not 3X faster code.
Of course if you do this opcode a lot of times, it would be somewhat
slower than if you do
2007/12/4, Gregory Beaver [EMAIL PROTECTED]:
Martin,
Please stop spreading misinformation.
[snip]
At least get your facts straight before posting.
Greg
Greg, that was uncalled for.
Isn't it a fact that the namespace keyword does more than just declare a
namespace in your current
However, in the global scope (no namespace) it would fail. This is a
bug that is easily fixed. use should allow re-aliasing of global
classes, and I could provide a very easy fix.
This is not a bug - since there you work with test::xmlreader, which of
course you can define. But in global
Unfortunately it also takes more memory in the common case (at least the apps
that we tested). It's not a significant amount more but it's a tiny bit more.
I'd say negligible.
Btw, I think I miswrote in my email. When you look at the benchmark results on
the new patch it's actually 1-2% slower
sense again. But Stas, consider (old dialect bc I need to update locally
sorry):
import nstest::test as whatever;
This works in the global space, right? Now along comes, say, Pierre or
Right.
Derick or Marcus with this class they just have to add to an existing
(non-namespaced) core
I can't. I can only hope they would do it right, I can't force them to do
it right :)
I guess what I'm really asking is, 'is there any point in allowing
import/use to be used in the global space?' I'm tired and etc, but I just
can't visualize where it would be useful.
Maybe one of the OO
I guess what I'm really asking is, 'is there any point in allowing
import/use to be used in the global space?' I'm tired and etc, but I just
can't visualize where it would be useful.
And now I've finished reading old South Park episodes...
OK, it's sinking in now. Because global import/use is
On Tue, 2007-12-04 at 22:26 -0600, Larry Garfield wrote:
On Tuesday 04 December 2007, Derick Rethans wrote:
4. What is wrong with simple prefixes in the first place? Both PEAR_*,
Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
'namespaces'. We could optionally
On Tuesday 04 December 2007, Derick Rethans wrote:
4. What is wrong with simple prefixes in the first place? Both PEAR_*,
Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
'namespaces'. We could optionally create a registry on php.net for
this to avoid conflicts.
I think support for multiple namespaces in one file should definitely be
used. As far as using curly braces vs using the namespace declaration,
it doesn't really matter to me, however it is important that i be able
to use the same namespace twice:
namespace a {
function function1() {
I think namespaces are very useful when it comes to PHP in large scale
applications with hundreds of functions/classes.
On Tue, 2007-12-04 at 16:39 -0600, Brian Moon wrote:
With all the above considerations, especially my first point, I still have
not
heard any good reason why namespaces
Hi Larry,
namespace me;
use Whatever as LegacyWhatever;
class Whatever{}
I'd missed that in the ebb and flow. I guess the bug in my copy was fixed
then, good. It still doesn't make sense to have global import though...?
(I'm probably going to kick myself sooo hard for this in the
On Dec 4, 2007 10:36 PM, Robert Cummings [EMAIL PROTECTED] wrote:
On Tue, 2007-12-04 at 22:26 -0600, Larry Garfield wrote:
On Tuesday 04 December 2007, Derick Rethans wrote:
4. What is wrong with simple prefixes in the first place? Both PEAR_*,
Zend_*, ezc*, and ezp* are perfectly
85 matches
Mail list logo
