A small addition:
the exact same test results in the following average times on my dev
machine:
with bundled classes: ~0.07s (~2-10 includes)
without: ~0.10s (~60-80 includes)
Thats ~30ms difference in average. I wanted to post that because the
results on my dev machine are much more constant than the one on the
vserver. And the xdebug profiling result shows me in fact that this
additional time seems to be spend in the autoload facility and its
require_once calls. These are the calls that are skipped when the big
class bundle is loaded in advance.
Regards
Roman
On Dec 4, 2007, at 10:48 AM, Roman Borschel wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
