Hi all,
The patch to implement multiple namespaces per file, and the patch to
remove keyword restrictions for methods appear to have fallen through
the cracks. I would like to encourage at the minimum a review, and
either a "go away" or a commit so we can still pretend that outsider
contributions have an impact on PHP, even those from annoying people
like me.
Thanks,
Greg
The patch to implement multiple namespaces per file, and the patch to
remove keyword restrictions for methods appear to have fallen through
the cracks. I would like to encourage at the minimum a review, and
About the second - I'm not sure which patch it is, I remember there was
a simple one and a more complex one. AFAIK, the simple one (making vars
and methods work the same) should be applied. Wasn't it?
As for multiple namespaces per file, it adds certain complications, both
syntax-wise and engine-wise, so I'm still not 100% convinced it is worth it.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
As for multiple namespaces per file, it adds certain complications, both
syntax-wise and engine-wise, so I'm still not 100% convinced it is worth
it.
Which are?
Remember, we both found, independently, that combining separate files
yields from a 10-30% performance increase. I have only talked to 2
developers who would be using namespaces that don't want this feature.
Of course, these two developers are the only people who would be using
namespaces with commit access to the Zend/ tree, but that doesn't make
the feature unnecessary. If you'd like, I could put you in contact with
developers who have been struggling with combining files for several
years now.
Anecdotally, I heard of a recent file-combining optimization to a very
popular CMS that resulted in a 45% performance improvement. Improving
the SQL queries led to only 9% improvement, so really the only reason
not to implement the multiple namespaces per-file patch is if you
actually want a large number of php devs to be annoyed at you :)
Thanks,
Greg
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 is around the 15% mark when combining
the files. This is with APC installed too.
I heard rumours however that php6 is not going to have such an issue with
inclusion performance (something about caching of the inheritance tree in
APC?).
I would just like to say that if there is still a performance issue in php6,
I would like to see the multiple namespaces per file functionality added.
But this is the only reason.
SCOTT MCNAUGHT
Software Developer
Synergy 8 / +617 3397 5212
scott.mcnaught@synergy8.com
-----Original Message-----
From: Gregory Beaver [mailto:greg@chiaraquartet.net]
Sent: Monday, 3 December 2007 5:30 PM
To: Stanislav Malyshev
Cc: internals Mailing List
Subject: Re: [PHP-DEV] ignored patches
Stanislav Malyshev wrote:
As for multiple namespaces per file, it adds certain complications, both
syntax-wise and engine-wise, so I'm still not 100% convinced it is worth
it.
Which are?
Remember, we both found, independently, that combining separate files
yields from a 10-30% performance increase. I have only talked to 2
developers who would be using namespaces that don't want this feature.
Of course, these two developers are the only people who would be using
namespaces with commit access to the Zend/ tree, but that doesn't make
the feature unnecessary. If you'd like, I could put you in contact with
developers who have been struggling with combining files for several
years now.
Anecdotally, I heard of a recent file-combining optimization to a very
popular CMS that resulted in a 45% performance improvement. Improving
the SQL queries led to only 9% improvement, so really the only reason
not to implement the multiple namespaces per-file patch is if you
actually want a large number of php devs to be annoyed at you :)
Thanks,
Greg
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 is around the 15% mark when combining
the files. This is with APC installed too.
Can you provide some benchmark setups that this could be researched -
i.e. describe what was benchmarked and how to reproduce it?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 is around the 15% mark when
combining
the files. This is with APC installed too.Can you provide some benchmark setups that this could be researched
- i.e. describe what was benchmarked and how to reproduce it?
I've seen this come up before internally at Facebook. Many people do
a microtime() test within there code and consider this a definitive
benchmark of how fast there script runs. Unfortunately this excludes
a lot of work that's done prior to execution. Typically we see
people claiming gains from combining files when in actuality they
where just excluding the compilation time in their benchmark by
moving compilation done via includes() to before the initial script
begins executing. When measuring this type of optimization one
really must measure outside of PHP using something like an Apache
Bench tool so you get an idea of the big picture. I think trying to
optimize these also presumes that you're already running a bytecode
cache etc.
-shire
Brian Shire 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 is around the 15% mark when
combining
the files. This is with APC installed too.Can you provide some benchmark setups that this could be researched -
i.e. describe what was benchmarked and how to reproduce it?I've seen this come up before internally at Facebook. Many people do a
microtime()test within there code and consider this a definitive
benchmark of how fast there script runs. Unfortunately this excludes a
lot of work that's done prior to execution. Typically we see people
claiming gains from combining files when in actuality they where just
excluding the compilation time in their benchmark by moving compilation
done via includes() to before the initial script begins executing. When
measuring this type of optimization one really must measure outside of
PHP using something like an Apache Bench tool so you get an idea of the
big picture. I think trying to optimize these also presumes that you're
already running a bytecode cache etc.
Hi Brian and Stas,
I hate to say it, but it is somewhat condescending to assume that the
benchmarks were done with microtime(). I spent about 15 hours of my
time designing a very complex, carefully constructed benchmark, and yes,
I ran it with apache benchmark. In addition, I ran the benchmark using
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.
An earlier benchmark compared a single file to using both require_once
and dirname(FILE) - a real performance killer that resulted in 19%
difference without APC, and 30% difference with APC.
Oh and before anyone gets any ideas about my competence, Stas tried the
same benchmark in Zend's ultra-high tech lab and got the same results.
These are not some loser's microtime() benchmark.
What is particularly irksome about this whole nightmare is the
combination of "prove it you little peon" attitude and the fact that it
doesn't really matter what evidence this little peon presents - the
decision appears to have already been made without any debate or
interest in work. At first I thought it was the annoyance of having to
come up with a patch, but I have also provided patches complete with
.phpt tests. If the decision is to ignore input, I would really rather
someone just say "piss off" instead of letting me waste several months
patiently proving that there is a performance difference that can
matter just so that it can be dismissed without consideration and vague
references to "it probably is really only a 5% difference."
Then I wouldn't have to waste more time writing messages like this one
that say: I've already proven there's a performance difference, the ball
is in your court to prove (with benchmark) that I am wrong.
Greg
Brian Shire 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 is around the 15% mark when
combining
the files. This is with APC installed too.Can you provide some benchmark setups that this could be
researched -
i.e. describe what was benchmarked and how to reproduce it?I've seen this come up before internally at Facebook. Many people
do a
microtime()test within there code and consider this a definitive
benchmark of how fast there script runs. Unfortunately this
excludes a
lot of work that's done prior to execution. Typically we see people
claiming gains from combining files when in actuality they where just
excluding the compilation time in their benchmark by moving
compilation
done via includes() to before the initial script begins
executing. When
measuring this type of optimization one really must measure
outside of
PHP using something like an Apache Bench tool so you get an idea
of the
big picture. I think trying to optimize these also presumes that
you're
already running a bytecode cache etc.Hi Brian and Stas,
I hate to say it, but it is somewhat condescending to assume that the
benchmarks were done withmicrotime(). I spent about 15 hours of my
time designing a very complex, carefully constructed benchmark, and
yes,
I ran it with apache benchmark. In addition, I ran the benchmark
using
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.
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 off-list as some of our performance problems may be
similar and I could exchange some optimizations with you to try out.
Again extremely sorry for insulting you or anyone else here with my
not so well thought out email, I'd just like to try to help out a bit.
-shire
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 off-list as some of our performance problems may be similar
and I could exchange some optimizations with you to try out.Again extremely sorry for insulting you or anyone else here with my
not so well thought out email, I'd just like to try to help out a bit.
Hi Brian,
Apology accepted, thanks. I'm sure we could all benefit from facebook's
profiling in-the-field knowledge when deciding how to proceed with these
new 5.3 features. Last I checked, facebook was pretty speedy on load,
so you must be doing something right.
Greg
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 45%, definitely. Now what exactly the
application you benchmarked did besides includes? Was it a real-life
app? Which one?
What is particularly irksome about this whole nightmare is the
combination of "prove it you little peon" attitude and the fact that it
It has nothing to do with "little peon". 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
abuse potential, so we need to be sure this performance improvement is
real and worth the troubles that this feature brings. Otherwise even
considering it is pointless - if we have no real performance improvement
on real applications, what worth it?
I still think namespace syntax is not the right place to improve
performance, but if I have real-life data it might be an argument for it.
.phpt tests. If the decision is to ignore input, I would really rather
Please stop it. If your single proposal is not accepted, it's not
"decision to ignore input". There are a lot of proposals to PHP
improvement, some of them get accepted, some of them get rejected.
Anybody who is interested in developing PHP and proposes anything with
any frequency is bound to have his share of proposals rejected, and
inevitably he would feel hurt - if he didn't think it's an excellent
proposal, he wouldn't propose it.
You can claim that some of them are rejected mistakenly, and it's a
valid difference of opinion. But claim that your input was ignored,
after extensive discussion and multiple verbose explanations of the
reasons to you is plain false.
that say: I've already proven there's a performance difference, the ball
is in your court to prove (with benchmark) that I am wrong.
Proving the negative is impossible. You can't prove there's no
performance improvement on some application under some condition - doing
this would require one to convert all existing applications to single
file and test them in all possible environments. However, proving real
life application difference would require only one application being
tested.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 abuse potential,
This might be a stupid idea, or it might not, so bear with me:
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?
- Steph
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 somebody on the list said it's so much faster, and any mark can
be set by anybody.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 somebody on the list said it's so much faster, and any mark can be
set by anybody.
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.
/me waits for the sky to fall on her head
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 multiple applications/libraries there...
- Steph
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
is around the 15% mark when combining the files. This is with APC
installed too.Can you provide some benchmark setups that this could be researched
- i.e. describe what was benchmarked and how to reproduce it?
I've seen this come up before internally at Facebook. Many people do
amicrotime()test within there code and consider this a definitive
benchmark of how fast there script runs. Unfortunately this excludes
a lot of work that's done prior to execution.
FWIW: Xdebug's xdebug_time_index() function does not have this issue, as
it starts in RINIT.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
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
tests were always "unprofessional" tests using microtime() and maybe
they're worth less because of that but i dont think they're worth
nothing. I've prepared an example online on a vserver that runs php
5.2.4 with apc enabled (no fancy settings, mostly defaults).
Without bundling, the application includes/requires between 50-80
files a request, mostly through an autoloader registered with
spl_autoload_register. And i think such a number of includes per
request are not uncommon for large OO projects that also use other
(OO) frameworks/libraries (like zend/symfony/doctrine/propel/
whatever). With the bundle, which contains all of the most-used
classes that are needed on every request, it's about 2-10 includes.
Here the links to the experimental project
With a bundled class library:
http://vaultforum.code-factory.org/forum/
And here without one:
http://vaultforum.code-factory.org/forum/?nobundle=true
Note that the number of included files as well as the rendering time
displayed at the bottom are of course pretty inaccurate due to the
things stated above but the effect gets pretty clear.
I can't exclude that this impact may have other reasons, so if this is
the case i'm happy about every suggestion. The only difference in the
two links makes this piece of code:
if ( ! isset($_GET['nobundle'])) {
require_once 'cache/classes.php';
}
If someone is interested in the full source, its here:
http://vaultforum.code-factory.org/trac/browser/trunk
The autoload method registered with spl_autoload_register is here:
http://vaultforum.code-factory.org/trac/browser/trunk/library/VForum.php
(Removing the preg_match did not have a noticeable performance
improvement when i tested that. In fact i commented it out in the code
used by the demonstration.)
I've got similar results, that means a noticeable difference between
unbundled/bundled, on my dev machine (OS X), too. So for me it seems
that such a bundle is really worth it and thats why i would like to be
able to create such bundles with namespaced/packaged classes, too but
if someone can show me that the problem lies somewhere else and that
the number of files is not the cause of this performance difference
i'm happy, too.
This is NOT meant to be the THE one demonstration that multiple
namespaces/packages per file have a right to exist, its just my
experiences with this issue and i wanted to throw them in.
Thanks.
Roman
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
is around the 15% mark when combining the files. This is with APC
installed too.Can you provide some benchmark setups that this could be researched
- i.e. describe what was benchmarked and how to reproduce it?
I've seen this come up before internally at Facebook. Many people do
amicrotime()test within there code and consider this a definitive
benchmark of how fast there script runs. Unfortunately this excludes
a lot of work that's done prior to execution.FWIW: Xdebug's xdebug_time_index() function does not have this
issue, as
it starts in RINIT.regards,
Derick--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
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 machine are much more constant than the one on the
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. These are the calls that are skipped when the big
class bundle is loaded in advance.
Regards
Roman
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 tests were always "unprofessional" tests usingmicrotime()
and maybe they're worth less because of that but i dont think
they're worth nothing. I've prepared an example online on a vserver
that runs php 5.2.4 with apc enabled (no fancy settings, mostly
defaults).
Without bundling, the application includes/requires between 50-80
files a request, mostly through an autoloader registered with
spl_autoload_register. And i think such a number of includes per
request are not uncommon for large OO projects that also use other
(OO) frameworks/libraries (like zend/symfony/doctrine/propel/
whatever). With the bundle, which contains all of the most-used
classes that are needed on every request, it's about 2-10 includes.Here the links to the experimental project
With a bundled class library:
http://vaultforum.code-factory.org/forum/And here without one:
http://vaultforum.code-factory.org/forum/?nobundle=trueNote that the number of included files as well as the rendering time
displayed at the bottom are of course pretty inaccurate due to the
things stated above but the effect gets pretty clear.
I can't exclude that this impact may have other reasons, so if this
is the case i'm happy about every suggestion. The only difference in
the two links makes this piece of code:if ( ! isset($_GET['nobundle'])) {
require_once 'cache/classes.php';
}If someone is interested in the full source, its here:
http://vaultforum.code-factory.org/trac/browser/trunkThe autoload method registered with spl_autoload_register is here:
http://vaultforum.code-factory.org/trac/browser/trunk/library/VForum.php(Removing the preg_match did not have a noticeable performance
improvement when i tested that. In fact i commented it out in the
code used by the demonstration.)I've got similar results, that means a noticeable difference between
unbundled/bundled, on my dev machine (OS X), too. So for me it seems
that such a bundle is really worth it and thats why i would like to
be able to create such bundles with namespaced/packaged classes, too
but if someone can show me that the problem lies somewhere else and
that the number of files is not the cause of this performance
difference i'm happy, too.This is NOT meant to be the THE one demonstration that multiple
namespaces/packages per file have a right to exist, its just my
experiences with this issue and i wanted to throw them in.Thanks.
Roman
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
is around the 15% mark when combining the files. This is with APC
installed too.Can you provide some benchmark setups that this could be researched
- i.e. describe what was benchmarked and how to reproduce it?
I've seen this come up before internally at Facebook. Many people
do
amicrotime()test within there code and consider this a definitive
benchmark of how fast there script runs. Unfortunately this
excludes
a lot of work that's done prior to execution.FWIW: Xdebug's xdebug_time_index() function does not have this
issue, as
it starts in RINIT.regards,
Derick--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
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 machine are much more constant than the one on the
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. These are the calls that are skipped when the big
class bundle is loaded in advance.
Hi Roman,
APC's fastest performance with separate files occurs with an
unconditional include statement with a full path. autoload always
occurs at runtime, which incurs higher overhead than an unconditional
include. Removing the include statements entirely by combining all code
into a single file results in even better performance. All code in 1
file is always faster than unconditionally including the code you use
which is always faster than using autoload to include the same code at
runtime, this is what the benchmark I ran showed conclusively.
However, if you have a complex app with many lines of code to include
and many classes, most of which are not used in a single request, you
might be able to get better performance from autoload than from an
unconditional include, simply because many fewer lines of code are
actually parsed, compensating for the slower performance of autoload.
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 simple arithmetic, but not all developers will
benefit from this approach, just as not all developers benefit from
using autoload.
Each app has a different need, my only goal with the multiple namespace
per-file patch is to make it possible to optimize by combining files
into a single file, as the existing PHP program space shows there are
already apps that can benefit from this approach.
Greg
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 simple arithmetic, but not all developers will
benefit from this approach, just as not all developers benefit from
using autoload.
Thats true but in my case i always deploy the class bundle along with
the "original" code so its very easy to switch between using the
bundle or using the real sources for debugging purposes. And its also
very easy to regenerate/recreate the bundle since this is an automated
process.
Thanks for the other hints!
Regards
Roman
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ő
Yes, thanks i already changed that. Doesnt make a big difference though.
Roman
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ő
Hi!
Can you provide some benchmark setups that this could be researched -
i.e. describe what was benchmarked and how to reproduce it?
I have already played with this topic. If you don't have an opcode cache
lazy loading is a good solution: it is worth loading a code only when
it is needed. But if you have opcode cache it is worth to put often used
includes into one big file.
I used the following test code:
<?php
$measurements = array();
$_GET += array("includeFileCardinality" => 9);
$_GET["includeFileCardinality"] =
min(max((int)$_GET["includeFileCardinality"], 1), 9);
$start = microtime(TRUE);
if ($_GET["includeFileCardinality"] >=1)
include_once("include.test/flash_config.php";);
if ($_GET["includeFileCardinality"] >=2)
include_once("include.test/access.php";);
if ($_GET["includeFileCardinality"] >=3)
include_once("include.test/awe_config.php";);
if ($_GET["includeFileCardinality"] >=4)
include_once("include.test/functions.php";);
if ($_GET["includeFileCardinality"] >=5)
include_once("include.test/domain_constants.php";);
if ($_GET["includeFileCardinality"] >=6)
include_once("include.test/categories.php";);
if ($_GET["includeFileCardinality"] >=7)
include_once("include.test/config.php";);
if ($_GET["includeFileCardinality"] >=8)
include_once("include.test/common.php";);
if ($_GET["includeFileCardinality"] >=9)
include_once("include.test/errorhandler.lib.php";);
$measurements["include - tobb kulon fajl"] = microtime(TRUE)-$start;
$start = microtime(TRUE);
include_once("include.test/_all_in_one.php";);
$measurements["include - egy nagy fajl"] = microtime(TRUE)-$start;
if (php_sapi_name() == "cli")
{
echo serialize($measurements);
}
else
{
header("Content-Type: text/html; charset=UTF-8");
displayMeasurments("Eredmények apache modul esetén", $measurements);
displayMeasurments("Eredmények CLI módban",
unserialize(shell_exec("php ".FILE)));
echo "
<form>
Az egyesével include-olt fájlok száma:<br>
<select name="includeFileCardinality" size="5">
<option value="1">1</option>
<option value="2">2</option>
<option value="3">3</option>
<option value="4">4</option>
<option value="5">5</option>
<option value="6">6</option>
<option value="7">7</option>
<option value="8">8</option>
<option value="9">9</option>
</select><br>
<input type="submit" value="Teszt">
</form>
";
}
function displayMeasurments($title, $measurements)
{
$fastestTime = min($measurements);
echo "<table border="1">\n<tr><td colspan="3"
align="center"><strong>".$title."</strong></td></tr>\n";
foreach($measurements as $testMethod => $elapsedTime)
{
echo "<tr><td>".$testMethod."</td>\n";
echo "<td>".$elapsedTime."</td>\n";
echo
"<td>".round($elapsedTime/$fastestTime*100)."%</td></tr>\n\n";
}
echo "</table>\n<br>";
}
?>
The files come from a real life project. I get the following result:
Results (apache module)
include - more files 0.000619888305664 307%
include - one big file 0.000202178955078 100%
I run the test code a lot of time, I get this characteristics always.
Then I tried the code on heavily IO loaded server (x100 req/sec+DB
replica) and the difference was bigger (5-600%).
Best Regards,
Felhő
Remember, we both found, independently, that combining separate files
yields from a 10-30% performance increase. I have only talked to 2
On synthetic benchmarks. On real apps, which do databases, calculations,
network, etc. that would be probably no more than 5%, probably even
less. And I don't see any application shipping in this format.
This is a very problematic issue - adding a feature into a language that
serves only very specific very narrow performance scenario but which
will inevitably be widely abused in cases which have nothing to do with
that scenario.
the feature unnecessary. If you'd like, I could put you in contact with
developers who have been struggling with combining files for several
years now.
Why were they "struggling" - only problem existing with it is
namespaces, and they certainly couldn't try to use namespaces for years?
If they had other problems, they will keep having them and multiple
namespaces per file are not going to help them.
Anecdotally, I heard of a recent file-combining optimization to a very
popular CMS that resulted in a 45% performance improvement. Improving
Did they use bytecode caching?
Anyway, I have hard time believing PHP include is so broken, but if it
is - it should be fixed, not through creating syntax-level workarounds
but directly.
really the only reason not to implement the multiple namespaces per-file
I think I described my reasons now multiple times.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi Stats,
Everybody is providing clear and proven results. You are the only one who is
throwing around hypothetical numbers (that 5% figure comes out of your
head). Can you please be more responsible and provide some real results ?
Also, pretty much every feature of a language can be abused. From my point
of view, using autoload for every class IS abusive (as we all know, thanks
to many benchmarks, that it affects performance negatively). But I don't
defend its abolition because of that.
Thank you kindly,
Nicolas.
Remember, we both found, independently, that combining separate files
yields from a 10-30% performance increase. I have only talked to 2On synthetic benchmarks. On real apps, which do databases, calculations,
network, etc. that would be probably no more than 5%, probably even
less. And I don't see any application shipping in this format.This is a very problematic issue - adding a feature into a language that
serves only very specific very narrow performance scenario but which
will inevitably be widely abused in cases which have nothing to do with
that scenario.the feature unnecessary. If you'd like, I could put you in contact with
developers who have been struggling with combining files for several
years now.Why were they "struggling" - only problem existing with it is
namespaces, and they certainly couldn't try to use namespaces for years?
If they had other problems, they will keep having them and multiple
namespaces per file are not going to help them.Anecdotally, I heard of a recent file-combining optimization to a very
popular CMS that resulted in a 45% performance improvement. ImprovingDid they use bytecode caching?
Anyway, I have hard time believing PHP include is so broken, but if it
is - it should be fixed, not through creating syntax-level workarounds
but directly.really the only reason not to implement the multiple namespaces
per-fileI think I described my reasons now multiple times.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
your head). Can you please be more responsible and provide some real
results ?
Results of what?
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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.
your head). Can you please be more responsible and provide some real
results ?Results of what?
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 seen no facts
on this, only on benchmarks - which is great, but experience teaches us
specialized benchmarks behave radically different from real-life apps.
5% figure is nothing but other way of saying "I think the improvement
would be small" - but of course, since I did not benchmark any, this
figure and this opinion is meaningless. To make meaningful opinion, real
benchmarks should be made. Unfortunately, I do not have any real
applications working in "bundled" scenario. This is why I ask people
that reportedly have this applications and benchmarked them, to help me.
Answering "prove we didn't have them" doesn't help much.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 Plumbing Supply
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 syscall? because that's the main
stumbling block here, at least as I understand it.
- Steph
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 syscall? because that's the main
stumbling block here, at least as I understand it.
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.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
2007/12/4, Michael McGlothlin michaelm@swplumb.com:
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?
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
bundling is not as easy as it seems, and its complexity is proportionally
inverse to the complexity of the language.
As much as you can try to improve this area, you can't do much without
resorting to hacks and workarounds. An option is becoming a managed-code
language such as Java or the .Net family.
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 bundling is not as easy as it seems, and its
complexity is proportionally inverse to the complexity of the language.As much as you can try to improve this area, you can't do much without
resorting to hacks and workarounds. An option is becoming a
managed-code language such as Java or the .Net family.
If your already doing bytecode caching how much benefit is there to bundling? In that case it seems the main slow downs would be the minor time involved in any actual system calls and whatever logic is done for imports. Unless you have a slow file system I can't imagine the actual file reads from disk being to big an issue. I have my file system keep a lot of stuff in RAM so that the disk doesn't actually have to be accessed very often. I do a lot of none-PHP programming that involves heavy file use and keeping it all in RAM makes it a lot faster. I can't see PHP making huge gains but they might help for people really worried about performance.
With my current project I sadly have to interface to a slow back end system that is a commercial ERP product so I can't do anything to speed it up directly. Very annoying. The best I can do is cache as much data as possible. We're dumping a buttload ($30,000+) of money into a new AIX server for the back end to try to get it up to a decent speed.
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.
--
Michael McGlothlin
Southwest Plumbing Supply
2007/12/4, Michael McGlothlin michaelm@swplumb.com:
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 bundling is not as easy as it seems, and its
complexity is proportionally inverse to the complexity of the language.As much as you can try to improve this area, you can't do much without
resorting to hacks and workarounds. An option is becoming a
managed-code language such as Java or the .Net family.
If your already doing bytecode caching how much benefit is there to
bundling? In that case it seems the main slow downs would be the minor time
involved in any actual system calls and whatever logic is done for imports.
[snip]
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.
I completely agree with you, I'm not saying that you can obtain an actual
benefit from bundling, but that no one can deny the fact that bundling can
improve performance. The actual problem is that it's usually considered that
better performance means more benefits. Performance at the cost of
maintainability is not a benefit, economically speaking. I'd rather invest
in better hardware than in the "leet team of php guru hackers".
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
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 but I think maintainability is
more important than performance (within reason). You can't help if some
of your users are trying to run your code on a 486. You can buy a pretty
nice server for $3000 these days. That's within almost any business's range.
--
Michael McGlothlin
Southwest Plumbing Supply
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:
-
Why is performance relevant to whether namespaces are implemented one per
file or many per file? -
I was under the impression namespaces were introduced to improve code
maintainability. Was I wrong?
That's all folks.
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:
- 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.
The current namespace implementation does not allow more than 1
namespace per file. These 2 files:
file1.php:
<?php
class a {}
?>
file2.php:
<?php
class b {}
?>
can be combined into this file:
<?php
class a {}
class b {}
?>
Simply by cut/paste and PHP will work.
These two files:
<?php
namespace A;
class a {}
?>
file2.php:
<?php
namespace A;
class b {}
?>
when combined into:
<?php
namespace A;
class a {}
namespace A;
class b {}
?>
result in a parse error.
- 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.
Greg
2007/12/4, Gregory Beaver greg@chiaraquartet.net:
Martin Alterisio wrote:
- 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]
As I said to Roman: Sorry but that still doesn't answer my question. That
answer the question of "why use bundling?".
Also, what you exposed shows that the bundling process that you're currently
using needs to be updated to take in consideration the inclusion of
namespaces in PHP.
- 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 that's the case, and if it was my problem, I'll be facing two
possibilities:
- I've chosen the wrong language or platform for this app
- I did a really poor design of the app where I either never took
performance into consideration, or my performance estimates where completely
wrong.
Martin Alterisio wrote:
2007/12/4, Gregory Beaver <greg@chiaraquartet.net
mailto:greg@chiaraquartet.net>: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]As I said to Roman: Sorry but that still doesn't answer my question.
That answer the question of "why use bundling?".
Yes it does, perhaps you misunderstand the answer? Let me rephrase:
because it is faster to bundle in some circumstances, and in some
circumstances significantly faster than any other possible optimizations.
Also, what you exposed shows that the bundling process that you're
currently using needs to be updated to take in consideration the
inclusion of namespaces in PHP.
see my reply to your other message. You're wrong, it's not possible to
reliably bundle files containing namespace/import statements as
currently implemented.> 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 that's the case, and if it was my problem, I'll be facing two
possibilities:
- I've chosen the wrong language or platform for this app
- I did a really poor design of the app where I either never took
performance into consideration, or my performance estimates where
completely wrong.
Sorry, your last statement does not add anything to the debate but
noise. We are discussing the multiple namespaces per file patch. If
you'd like to discuss which programming language to use or talk about
hypothetical programming techniques, try php-general or IRC.
Greg
2007/12/4, Gregory Beaver greg@chiaraquartet.net:
Martin Alterisio wrote:
2007/12/4, Gregory Beaver <greg@chiaraquartet.net
mailto:greg@chiaraquartet.net>: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]As I said to Roman: Sorry but that still doesn't answer my question.
That answer the question of "why use bundling?".
Yes it does, perhaps you misunderstand the answer? Let me rephrase:
because it is faster to bundle in some circumstances, and in some
circumstances significantly faster than any other possible optimizations.
I just want to have an objective view of the problem. Right now I could care
less about namespaces being one per file, many per file, called packages,
namespaces, zendspaces or whatever. The only thing I care right now is that,
as a fellow php developer, I want to be sure that the ones running the show
have objective information to take a decision.
The only thing I see lately in this debate is performance comparison of
bundled and unbundled code. How's that relevant to decide whether namespaces
should be one per file or many per file?
Answering "bundling increases performance and performance is better" does
not answer this question. If it was just about performance we could just go
back to writing CGIs in C.
As I see it now, the objection to how namespaces are implemented is biased
towards the specific needs of a group of developers. Shouldn't you try first
if you can adjust your requirements to the new features rather than adjust
the language to your requirements?
Also, what you exposed shows that the bundling process that you're
currently using needs to be updated to take in consideration the
inclusion of namespaces in PHP.
see my reply to your other message. You're wrong, it's not possible to
reliably bundle files containing namespace/import statements as
currently implemented.
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.
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 wrong. The patch resets import at each
namespace declaration. Each chunk (as far as namespace and import
declarations) acts as its own file. global variables, constants, and
everything else that would carry over from file to file if included
continues to function normally.
The point of the patch is that it functions the same way as separate or
as 1 file.
Greg
2007/12/4, Gregory Beaver greg@chiaraquartet.net:
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 wrong. The patch resets import at each
namespace declaration. Each chunk (as far as namespace and import
declarations) acts as its own file. global variables, constants, and
everything else that would carry over from file to file if included
continues to function normally.
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;
namespace yadayada;
?
Quoting Martin Alterisio malterisio777@gmail.com:
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;
namespace yadayada;
Why is this an issue for you? That second example is currently a parse
error - the namespace declaration must be the first thing in the file,
so the order is significant now.
-chuck
2007/12/4, Chuck Hagenbuch chuck@horde.org:
Quoting Martin Alterisio malterisio777@gmail.com:
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;
namespace yadayada;Why is this an issue for you? That second example is currently a parse
error - the namespace declaration must be the first thing in the file,
so the order is significant now.
It's an issue since it's something the patch will allow if implemented.
Martin Alterisio wrote:
2007/12/4, Chuck Hagenbuch chuck@horde.org:
Quoting Martin Alterisio malterisio777@gmail.com:
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;
namespace yadayada;
Why is this an issue for you? That second example is currently a parse
error - the namespace declaration must be the first thing in the file,
so the order is significant now.It's an issue since it's something the patch will allow if implemented.
Martin,
Please stop spreading misinformation. The patch will not allow that.
It will allow:
<?php
namespace Blah;
import yadayada;
...
namespace Foo;
import yadayada;
?>
<?php
import yadayada;
namespace Blah;
?>
is still a parse error.
At least get your facts straight before posting.
Greg
2007/12/4, Gregory Beaver greg@chiaraquartet.net:
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 patch?
Isn't it a fact that the behavior of the namespace keyword in that patch can
lead to confusion, because the order of statements matter and, after the
first namespace, the namespace keyword won't fail even if it's not the first
statement.
Also, there has been too much ado about the patch, if namespaces should be
bracketed or not, if import has scope or not, if imports can be unset or
not, etc. The patch itself has changed much in little time. Look at it from
the php community perspective: we're getting anxious.
With all this much ado, how can you expect me, or anyone, to keep up with
the whole thing? Misinformation was never my intention, rather than that, I
consider myself misinformed about this whole topic.
PS: I'm sorry to post again on this rather closed thread. I got home and
when I saw this mail I was quite shocked, as it was and answer I wasn't
expecting. I felt compelled to write a response, which I promise will be the
last. Greg: you should know when to step back.
- I was under the impression namespaces were introduced to improve
codemaintainability. 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 that's the case, and if it was my problem, I'll be facing two
possibilities:
- I've chosen the wrong language or platform for this app
- I did a really poor design of the app where I either never took
performance into consideration, or my performance estimates where
completely
wrong.
Of course the performance of the application itself and the
performance of my code is the first place where i look. I dont shift
this burden to php just because im lazy.
As far as I understood it the patch that will support multiple
namespaces/packages per file is a minor patch and the only argument
against it were that it can lead to bad practices, with which i can't
really agree as this argument could be used against many features.
(If there are implementation issues which im not aware of then i'm
sorry, i'm not that deep into php-dev).
Thats why I don't really understand the whole trouble that is caused
by this. Noone will force you to write bad code.
Roman