# ignored patches

- Thread: https://externals.io/message/33043
- Original archive: https://news-web.php.net/php.internals/33043
- Started by Gregory Beaver on 2007-11-07T02:48:44+00:00
- Messages: 55
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/33043.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #33043 — Gregory Beaver — 2007-11-07T02:48:44+00:00

URL: https://externals.io/message/33043#33043

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

---

## #33047 — Stanislav Malyshev — 2007-11-07T17:44:23+00:00

URL: https://externals.io/message/33043#33047 · In reply to: #33043

> 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

---

## #33579 — Gregory Beaver — 2007-12-03T07:30:15+00:00

URL: https://externals.io/message/33043#33579 · In reply to: #33047

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

---

## #33580 — scott.mcnaught@synergy8.com — 2007-12-03T08:00:55+00:00

URL: https://externals.io/message/33043#33580 · In reply to: #33579

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

---

## #33608 — Stanislav Malyshev — 2007-12-03T22:16:17+00:00

URL: https://externals.io/message/33043#33608 · In reply to: #33579

> 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

---

## #33609 — Stanislav Malyshev — 2007-12-03T22:17:31+00:00

URL: https://externals.io/message/33043#33609 · In reply to: #33580

> 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

---

## #33616 — nicobn@gmail.com — 2007-12-04T00:05:38+00:00

URL: https://externals.io/message/33043#33616 · In reply to: #33608

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 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.
>
> > […]
>
> 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.
>
> > […]
>
> 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.
>
> > […]
> 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

---

## #33617 — Brian Shire — 2007-12-04T00:13:34+00:00

URL: https://externals.io/message/33043#33617 · In reply to: #33609

> > […]
>
> 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

---

## #33618 — Gergely Hodicska — 2007-12-04T00:42:47+00:00

URL: https://externals.io/message/33043#33618 · In reply to: #33609

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ő

---

## #33625 — Gregory Beaver — 2007-12-04T05:16:16+00:00

URL: https://externals.io/message/33043#33625 · In reply to: #33617

Brian Shire wrote:
> 
> 
> 
> > […]
> 
> 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

---

## #33628 — Brian Shire — 2007-12-04T06:58:25+00:00

URL: https://externals.io/message/33043#33628 · In reply to: #33625

> Brian Shire wrote:
> > […]
>
> 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

---

## #33630 — Derick Rethans — 2007-12-04T08:26:24+00:00

URL: https://externals.io/message/33043#33630 · In reply to: #33617

> 
> 
> > […]
> 
> 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

---

## #33634 — Roman Borschel — 2007-12-04T09:48:59+00:00

URL: https://externals.io/message/33043#33634 · In reply to: #33630

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



> 
>
> > […]
>
> 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

---

## #33639 — Roman Borschel — 2007-12-04T14:08:41+00:00

URL: https://externals.io/message/33043#33639 · In reply to: #33634

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 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
>
> 
>
> > […]

---

## #33645 — Martin Alterisio — 2007-12-04T16:09:07+00:00

URL: https://externals.io/message/33043#33645 · In reply to: #33043

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.

---

## #33646 — Gregory Beaver — 2007-12-04T16:13:31+00:00

URL: https://externals.io/message/33043#33646 · In reply to: #33628

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

---

## #33647 — Gregory Beaver — 2007-12-04T16:14:14+00:00

URL: https://externals.io/message/33043#33647 · In reply to: #33639

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

---

## #33648 — Roman Borschel — 2007-12-04T16:25:09+00:00

URL: https://externals.io/message/33043#33648 · In reply to: #33647

> 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

---

## #33649 — Gregory Beaver — 2007-12-04T16:31:17+00:00

URL: https://externals.io/message/33043#33649 · In reply to: #33645

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

---

## #33651 — Martin Alterisio — 2007-12-04T16:50:31+00:00

URL: https://externals.io/message/33043#33651

2007/12/4, Roman Borschel <r.borschel@gmx.net>:
>
> 
> > […]
>
> Because including/requiring 80 files one by one seems to be
> significantly slower than including/requiring just a few files.


Sorry but that still doesn't answer my question. That answer the question of
"why use bundling?".

>
> > […]
>
> Of course. Such bundling processes usually only take place during an
> automated build process. This is not something thats used for
> development.


I didn't understand. Do you mean that I was wrong? Or that I was right about
namespaces purpose, but that's only needed in development? Therefore,
shouldn't the bundling process remove the need for namespaces (i.e. the
bundling process removes namespaces)?

Aside form that, is it not coherent that a whole namespace conforms one
bundle? Why should namespaces mix?

---

## #33652 — Martin Alterisio — 2007-12-04T17:00:28+00:00

URL: https://externals.io/message/33043#33652 · In reply to: #33649

2007/12/4, Gregory Beaver <greg@chiaraquartet.net>:
>
> Martin Alterisio wrote:
> > […]
> per
> > […]
>
> 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
> > […]
>
> 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.

---

## #33655 — Gregory Beaver — 2007-12-04T17:07:17+00:00

URL: https://externals.io/message/33043#33655 · In reply to: #33651

Martin Alterisio wrote:
> I didn't understand. Do you mean that I was wrong? Or that I was right about
> namespaces purpose, but that's only needed in development? Therefore,
> shouldn't the bundling process remove the need for namespaces (i.e. the
> bundling process removes namespaces)?

You can't expand classes in different namespaces as class Blah::Blah {}
is not possible.

In addition, by forcing code modifications on creating the bundle, you
introduce a level of complexity that can introduce subtle but critical
bugs, simply because the code being executed is different from the
pre-existing code.  Having done this kind of work for years with PEAR in
the install phars for a different reason, I can say definitively that
any code modifications that are required to make something work in an
automatic fashion introduce a level of magic that is brittle and much
less maintainable.

> Aside form that, is it not coherent that a whole namespace conforms one
> bundle? Why should namespaces mix?

That's a developer's choice.  The current implementation forces it to be
so, with code modifications.  In addition, you would need to check for
all import clauses and replace them, as combining these files is a fatal
error:

<?php
namespace A;
class a {}
?>
<?php
namespace A;
import a as b;
class c extends b {}
?>
<?php
namespace A;
class b {}
?>

So in other words, without the simple 10-line patch to zend_compile.c
allowing combining of namespaces into a single file, you just can't
reliably combine multiple files containing a namespace statement even in
the same namespace, no matter what foobar magic your bundling script
practices.

Greg

---

## #33653 — Gergely Hodicska — 2007-12-04T17:10:39+00:00

URL: https://externals.io/message/33043#33653 · In reply to: #33639

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

---

## #33654 — Roman Borschel — 2007-12-04T17:13:35+00:00

URL: https://externals.io/message/33043#33654 · In reply to: #33651

> 2007/12/4, Roman Borschel <r.borschel@gmx.net>:
> > […]
> Sorry but that still doesn't answer my question. That answer the  
> question of
> "why use bundling?".

Sorry, then i don't understand the question.

>
> > […]
>
>
> I didn't understand. Do you mean that I was wrong?

You were right. Namespaces are being introduced to improve code  
maintainability & readability.

> Or that I was right about
> namespaces purpose, but that's only needed in development? Therefore,
> shouldn't the bundling process remove the need for namespaces (i.e.  
> the
> bundling process removes namespaces)?

No because the whole code will use namespaces and just removing the  
namespace declarations during bundling will break the code.

---

## #33656 — Gregory Beaver — 2007-12-04T17:19:29+00:00

URL: https://externals.io/message/33043#33656 · In reply to: #33652

Martin Alterisio wrote:
> 2007/12/4, Gregory Beaver <greg@chiaraquartet.net
> <mailto:greg@chiaraquartet.net>>:
>
>     Martin Alterisio wrote:
> > […]
>     implemented one per
> > […]
>
>     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.
>
> > […]
>     improve code
> > […]
>
>     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

---

Next page: https://externals.io/message/33043.md?page=2