Everything

php

ignored patches

php.internals

Greg Beaver

18 years ago

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

Stanislav Malyshev

18 years ago

> 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

Greg Beaver

18 years ago

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

Unnamed Person

18 years ago

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Stanislav Malyshev

18 years ago

> 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

Brian Shire

18 years ago

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 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

Greg Beaver

18 years ago

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 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

18 years ago

On Dec 3, 2007, at 9:16 PM, Gregory Beaver wrote:

> 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 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.

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

Greg Beaver

18 years ago

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

Stanislav Malyshev

18 years ago

> 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

Steph

18 years ago

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

Stanislav Malyshev

18 years ago

> 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

Derick Rethans

18 years ago

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
> > > 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.

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

18 years ago

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

On Dec 4, 2007, at 9:26 AM, Derick Rethans wrote:

Roman Borschel

18 years ago

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

On Dec 4, 2007, at 10:48 AM, Roman Borschel wrote:

Greg Beaver

18 years ago

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

Hodicska Gergely

18 years ago

> 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ő

Hodicska Gergely

18 years ago

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ő

Stanislav Malyshev

18 years ago

> 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

Nicolas Bérard Nault

18 years ago

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.

On Dec 3, 2007 5:16 PM, Stanislav Malyshev <stas@zend.com> wrote:

Stanislav Malyshev

18 years ago

> 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

Nicolas Bérard Nault

18 years ago

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 <stas@zend.com> wrote:

Stanislav Malyshev

18 years ago

> 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

Michael McGlothlin

18 years ago

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

Steph

18 years ago

> 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

Martin Alterisio

18 years ago

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.

Martin Alterisio

18 years ago

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 file?

2) I was under the impression namespaces were introduced to improve code
maintainability. Was I wrong?

That's all folks.

Greg Beaver

18 years ago

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 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.

> 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.

Greg

Martin Alterisio

18 years ago

2007/12/4, Gregory Beaver <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?".

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.

> 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:
1) I've chosen the wrong language or platform for this app
2) I did a really poor design of the app where I either never took
performance into consideration, or my performance estimates where completely
wrong.

Greg Beaver

18 years ago

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:
> 1) I've chosen the wrong language or platform for this app
> 2) 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

Martin Alterisio

18 years ago

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.

Greg Beaver

18 years ago

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

Martin Alterisio

18 years ago

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;

?

Chuck Hagenbuch

18 years ago

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

Martin Alterisio

18 years ago

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.

Roman Borschel

18 years ago

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 that's the case, and if it was my problem, I'll be facing two
> possibilities:
> 1) I've chosen the wrong language or platform for this app
> 2) 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