Re: [PHP-DEV] ignored patches
Hi! Yes, that's my point - 3X faster include opcode is not 3X faster code. Of course if you do this opcode a lot of times, it would be somewhat slower than if you do this opcode just one time. However, the question is how it would influence the whole application? I didn't say that the code will be 3x faster, the main point is that you can gain considerable performance improvement. Of course this is only one factor of optimization, but not a negligible one. http://www.schlossnagle.org/~george/talks/ZendPerf.pdf I don't guess. Why guess if I can ask you? Maybe you should presume that the other is not a dummy (of course it could happen :)). (I tried the test more time and I get always this results.) Best Regards, Felhő -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
On Dec 6, 2007 12:05 PM, Gergely Hodicska [EMAIL PROTECTED] wrote: Hi! Yes, that's my point - 3X faster include opcode is not 3X faster code. Of course if you do this opcode a lot of times, it would be somewhat slower than if you do this opcode just one time. However, the question is how it would influence the whole application? I didn't say that the code will be 3x faster, the main point is that you can gain considerable performance improvement. Of course this is only one factor of optimization, but not a negligible one. http://www.schlossnagle.org/~george/talks/ZendPerf.pdf I don't guess. Why guess if I can ask you? Maybe you should presume that the other is not a dummy (of course it could happen :)). (I tried the test more time and I get always this results.) It is not about being stupid/dummy/whatever. The problem and no matter how good/bad you are is to have to worry about such things with a high level languages. include/require and their brother include_once/require_once have rocked for simple code inclusion in our all-in-one scripts or templates. But they are a pain to use as package (like import DB.* as myDB). As far as I remember, PHP did not want such concepts of package. I think it is pretty much what everyone is looking for, to supercede include/require in php libraries/apps (not in templates) and to fantastically improved our namespaces (which are not namespaces anyway but basic aliases). /fud --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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.
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
On Dec 4, 2007, at 5:14 PM, Gregory Beaver wrote: On the other hand, combining multiple files into a single file results in line numbers no longer corresponding to the original line numbers of the file, adding another translation step when debugging a problem. Of course, this is just 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
2007/12/4, Roman Borschel [EMAIL PROTECTED]: On Dec 4, 2007, at 5:09 PM, Martin Alterisio wrote: 1) Why is performance relevant to whether namespaces are implemented one per file or many per file? Because including/requiring 80 files one by one seems to be significantly slower than including/requiring just a few files. Sorry but that still doesn't answer my question. That answer the question of why use bundling?. 2) I was under the impression namespaces were introduced to improve code maintainability. Was I wrong? 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?
Re: [PHP-DEV] ignored patches
2007/12/4, Gregory Beaver [EMAIL PROTECTED]: Martin Alterisio wrote: 1) Why is performance relevant to whether namespaces are implemented one per file or many per file? Because there is a performance difference between code in separate files and the same code in a single file. [snip] 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.
Re: [PHP-DEV] ignored patches
vserver. And the xdebug profiling result shows me in fact that this additional time seems to be spend in the autoload facility and its require_once calls. OFF: require_once in autoload is not logical to me. Best Regards, Felhő -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
On Dec 4, 2007, at 5:50 PM, Martin Alterisio wrote: 2007/12/4, Roman Borschel [EMAIL PROTECTED]: On Dec 4, 2007, at 5:09 PM, Martin Alterisio wrote: 1) Why is performance relevant to whether namespaces are implemented one per file or many per file? Because including/requiring 80 files one 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?. Sorry, then i don't understand the question. 2) I was under the impression namespaces were introduced to improve code maintainability. Was I wrong? 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? 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
Martin Alterisio wrote: 2007/12/4, Gregory Beaver [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Martin Alterisio wrote: 1) Why is performance relevant to whether namespaces are implemented one per file or many per file? Because there is a performance difference between 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
Yes, thanks i already changed that. Doesnt make a big difference though. Roman On Dec 4, 2007, at 6:10 PM, Gergely Hodicska wrote: vserver. And the xdebug profiling result shows me in fact that this additional time seems to be spend in the autoload facility and its require_once calls. OFF: require_once in autoload is not logical to me. Best Regards, Felhő -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
your head). Can you please be more responsible and provide some real results ? Results of what? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
You are putting forward some hypothetical results. I want to know, for the benefit of the discussion, if you can prove the 5% figure you've advanced. On Dec 4, 2007 12:36 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: your head). Can you please be more responsible and provide some real results ? Results of what? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [PHP-DEV] ignored patches
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
2007/12/4, Gregory Beaver [EMAIL PROTECTED]: Martin Alterisio wrote: 2007/12/4, Gregory Beaver [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Martin Alterisio wrote: 1) Why is performance relevant to whether namespaces are implemented one per file or many per file? 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.
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
2007/12/4, Michael McGlothlin [EMAIL PROTECTED]: The need to pack a program all into a single source file for performance reasons would seem to indicate that the way PHP compiles/interprets could be improved. Wouldn't it be better to improve this area than add language features to deal with 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.
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
I strongly suspect performance difference in bundles does not follow from syscalls. On include() PHP does a lot more than just issue a couple of syscalls. So Michael's right and it needs some proper investigation. - Steph -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
2007/12/4, Gregory Beaver [EMAIL PROTECTED]: Martin Alterisio wrote: It's also not possible to reliably bundle files even if you could have multiple namespaces declarations as, correct me if I'm wrong, import statements affect the whole file, there is no way to unimport, a name clash 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; ?
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
2007/12/4, Michael McGlothlin [EMAIL PROTECTED]: Actually, it's an expected tradeoff of interpreted languages. Compilable languages have both a compiler and a linker that bundles everything in one executable. By using bytecode caching and bundling you're just getting closer to the 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.
Re: [PHP-DEV] ignored patches
Quoting Martin Alterisio [EMAIL PROTECTED]: Knowing that I'll have to strongly encourage the developers to dump that patch. The namespace declaration shouldn't do more than what it's expected to do. Why this: namespace yadayada; import yadayada; Should work different that: import yadayada; 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
I'm a firm believer that it's better to throw more CPU power at a performance problem than to make code less maintainable. Just buy a faster server. That hardly applies to library developers, though. They don't have control over their users' CPU power... - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
2007/12/4, Chuck Hagenbuch [EMAIL PROTECTED]: Quoting Martin Alterisio [EMAIL PROTECTED]: Knowing that I'll have to strongly encourage the developers to dump that patch. The namespace declaration shouldn't do more than what it's expected to do. Why this: namespace yadayada; import 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.
Re: [PHP-DEV] ignored patches
I used the following test code: What do these included file do? Is it part of some real-life application? From my previous mail: The files come from a real life project., the site has almost 80 million hit per day. DO they do any work besides being included? No, I put the codes in the files inside an if (0), I wanted to test only the include. Such small numbers should be measured repeatedly - 4ms difference can come from anywhere. Did you try repeated measurements? You are amazing. :) What do you guess? ;) Best Regards, Felh#337; -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
Martin Alterisio wrote: 2007/12/4, Chuck Hagenbuch [EMAIL PROTECTED]: Quoting Martin Alterisio [EMAIL PROTECTED]: Knowing that I'll have to strongly encourage the developers to dump that patch. The namespace declaration shouldn't do more than what it's expected to do. Why this: namespace 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
DO they do any work besides being included? No, I put the codes in the files inside an if (0), I wanted to test only the include. Yes, that's my point - 3X faster include opcode is not 3X faster code. Of course if you do this opcode a lot of times, it would be somewhat slower than if you do this opcode just one time. However, the question is how it would influence the whole application? Such small numbers should be measured repeatedly - 4ms difference can come from anywhere. Did you try repeated measurements? You are amazing. :) What do you guess? ;) I don't guess. Why guess if I can ask you? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
2007/12/4, Gregory Beaver [EMAIL PROTECTED]: Martin, Please stop spreading misinformation. [snip] At least get your facts straight before posting. Greg Greg, that was uncalled for. Isn't it a fact that the namespace keyword does more than just declare a namespace in your current 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.
RE: [PHP-DEV] ignored patches
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 [EMAIL PROTECTED] -Original Message- From: Gregory Beaver [mailto:[EMAIL PROTECTED] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 [EMAIL PROTECTED] wrote: 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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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
/selectbr
input type=\submit\ value=\Teszt\
/form
;
}
function displayMeasurments($title, $measurements)
{
$fastestTime = min($measurements);
echo table border=\1\\ntrtd colspan=\3\
align=\center\strong.$title./strong/td/tr\n;
foreach($measurements as $testMethod = $elapsedTime)
{
echo trtd.$testMethod./td\n;
echo td.$elapsedTime./td\n;
echo
td.round($elapsedTime/$fastestTime*100).%/td/tr\n\n;
}
echo /table\nbr;
}
?
The files come from a real life project. I get the following result:
Results (apache module)
include - more files0.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ő
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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
Re: [PHP-DEV] ignored patches
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
