RE: [PHP-DEV] Re: namespace RFC
Hello guys,
I just had to write you guys to give you some "real-life" examples.
We're working here at a PHP framework, named ALFA PHP Framework, that's
rather unique in the way that it enforces strong types in every method
(using classes for basic data types). We have our files organized this way:
- /inc/ directory = all BASE classes, auto-loaded by a "cached"
scandir (), loaded in a carefully calculated sequential order.
- /mod/user_authentification
- /mod/admin_cp - which are two MODULE classes that we load when we
need more functionality. We selectively load any modules we need.
As a benchmark, we have somewhere around 10 BASE classes, in 10 PHP
files, and about 10.000 LINES, and loading them takes just 0.00024 seconds
on a Core Duo machine. (0.0006 on an uniproc). We've actually gone further
and we "bypass" some scandir () methods by cacheing them in the _SESSION
variable, if we detected a proper user session once the platform has been
loaded. We don't use __autoload because it doesn't fit our need for
"carefull organized loading".
My conclusion is, that any "real-life" application, well-designed
would do "auto-loading" just for some base-classes, like we do here, and any
other dependencies like "developer required modules", will be cached some
way. We for example do a /per user caching of information, but other
developers can find other mechanism to cache this information, like a DB
result, or anything else.
I for once disagree with "each target (like each page, MVC action,
etc.) would have its own huge PHP file that has all classes used there",
because real-life apps need a dynamic approach, and as said earlier, any
GOOD designed app, will inherently think of a caching mechanism for it's
"loading/require/include" scheme. To accomplish this we actually went for
require_once on a module using an object $MOD->activateRegisteredModule
('user_authentification') - which scandirs () the array, caches the array,
quickly loads them in succession.
In the case of namespaces, PHP should be tunned for PHP classes
loaded in succession, or, if that is a problem, make the parser add
clases/code to the namespace when it detects a "namespace Something" token.
Regarding the need of PHP developers to have extensive C++
knowledge, I really don't care. I come from a C++ background, and any PHP
developer that doesn't understand C++ cannot be called "a developer". Guys,
I work as a Software Architect in Bucharest, Romania, and the quality of PHP
developers is questionable, due to the "easiness" of the PHP language. If
any amount of complication is needed, do it, and stop worrying about "PHP
developers". Real-life PHP developers are on this mailing-list, talking to
you guys, issuing bugs, doing real-life work. Don't make sacrifices just to
keep the language simple. Just go "full throttle forward!"
Regards,
Catalin Z. Alexandru
-Original Message-----
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 02, 2008 8:02 PM
To: Marcus Boerger
Cc: Gregory Beaver; Lukas Kahwe Smith; PHP Internals List
Subject: Re: [PHP-DEV] Re: namespace RFC
Hi!
> My guess is that it allows for development with heavy __autload usage and
> then doing deployment based on static analysis where each target page
> results in one large php file generated from that analysis. So there won't
> be any overhead and each script target would be a single target of its
own.
So each target (like each page, MVC action, etc.) would have its own
huge PHP file that has all classes used there? I guess for some
applications that could work, for others, more dynamic, that would fail
miserably. The maintainability of such thing is also challenging.
It would be nice to have some real-life examples of how such things work
out - so far I have seen only theory and synthetic benchmarks, which are
interesting, but not necessary what would happen on real project.
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: namespace RFC
Hi! My guess is that it allows for development with heavy __autload usage and then doing deployment based on static analysis where each target page results in one large php file generated from that analysis. So there won't be any overhead and each script target would be a single target of its own. So each target (like each page, MVC action, etc.) would have its own huge PHP file that has all classes used there? I guess for some applications that could work, for others, more dynamic, that would fail miserably. The maintainability of such thing is also challenging. It would be nice to have some real-life examples of how such things work out - so far I have seen only theory and synthetic benchmarks, which are interesting, but not necessary what would happen on real project. -- 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] Re: namespace RFC
Hello Stanislav, Tuesday, September 2, 2008, 9:51:38 AM, you wrote: > Hi! >> The problem is that the loading/unloading of the scanner and parser can >> be significant overhead, and by cramming all code into a single file, >> can result in a 10%-30% performance improvement over code in separate >> files, even with an opcode cache. This has been verified independently > Not only this, but the fact that executing 50 different op-arrays, with > all setup and teardown that happens on the way, is definitely slower > than 1 op-array, and also the fact that early binding on compile stage > may be a bit faster when we are dealing with a lot of classes and > carefully arrange them. > As always, note that the benchmark was loading huge amount of classes > and doing nothing but, so don't expect your real-life app to get > anywhere near 30% on that. Actually, I have no idea how hard it would be > to make big app using a lot of modules and lot of different classes in > different modules to work this way, so I'm not even sure it's practical > or will give any benefit - since you might be loading a bunch of code > you'd never need. But the effect does exist. My guess is that it allows for development with heavy __autload usage and then doing deployment based on static analysis where each target page results in one large php file generated from that analysis. So there won't be any overhead and each script target would be a single target of its own. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: namespace RFC
Hi! The problem is that the loading/unloading of the scanner and parser can be significant overhead, and by cramming all code into a single file, can result in a 10%-30% performance improvement over code in separate files, even with an opcode cache. This has been verified independently Not only this, but the fact that executing 50 different op-arrays, with all setup and teardown that happens on the way, is definitely slower than 1 op-array, and also the fact that early binding on compile stage may be a bit faster when we are dealing with a lot of classes and carefully arrange them. As always, note that the benchmark was loading huge amount of classes and doing nothing but, so don't expect your real-life app to get anywhere near 30% on that. Actually, I have no idea how hard it would be to make big app using a lot of modules and lot of different classes in different modules to work this way, so I'm not even sure it's practical or will give any benefit - since you might be loading a bunch of code you'd never need. But the effect does exist. -- 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] Re: namespace RFC
Hello Gregory, Sunday, August 31, 2008, 10:04:23 PM, you wrote: > Lukas Kahwe Smith wrote: >> Hello all, >> >> All the recent discussions about namespaces, have left many of us >> wondering if our implementation is rock solid or not. However the >> discussions were not really well organized. This is why I am thankful >> that Marcus and Felipe have spend the better part of this Sunday to >> write an RFC [1] that hopefully summarizes all the key concerns. Also >> they have created a patch that they feel addresses the concerns. >> >> So I ask you all to review the RFC and provide feedback. If you feel >> something is missing, the best approach is probably to work with Marcus >> and Felipe directly to get your concerns added. Only if there is a >> difference of opinion in this process should this be brought to >> internals. This way we can hopefully keep the discussion more focused on > Hi, > This is not a difference of opinion, but I would like to correct a > misconception: phar does *not* solve the problem that prompts > developers to concatenate files. > The problem is that the loading/unloading of the scanner and parser can > be significant overhead, and by cramming all code into a single file, > can result in a 10%-30% performance improvement over code in separate > files, even with an opcode cache. This has been verified independently > by Zend labs (Stanislav can attest to this) on their machines. The > performance difference depends on whether external code is loaded using > require with absolute path, require_once with relative path, autoload, > or some mix of these. > The problem requires streamlining of the loading process for files, and > could perhaps be addressed by attacking the bottleneck, but is not a > trivial problem to solve. > Just wanted to set the record straight. Please add that info to the rFC. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: namespace RFC
Lukas Kahwe Smith wrote: > Hello all, > > All the recent discussions about namespaces, have left many of us > wondering if our implementation is rock solid or not. However the > discussions were not really well organized. This is why I am thankful > that Marcus and Felipe have spend the better part of this Sunday to > write an RFC [1] that hopefully summarizes all the key concerns. Also > they have created a patch that they feel addresses the concerns. > > So I ask you all to review the RFC and provide feedback. If you feel > something is missing, the best approach is probably to work with Marcus > and Felipe directly to get your concerns added. Only if there is a > difference of opinion in this process should this be brought to > internals. This way we can hopefully keep the discussion more focused on Hi, This is not a difference of opinion, but I would like to correct a misconception: phar does *not* solve the problem that prompts developers to concatenate files. The problem is that the loading/unloading of the scanner and parser can be significant overhead, and by cramming all code into a single file, can result in a 10%-30% performance improvement over code in separate files, even with an opcode cache. This has been verified independently by Zend labs (Stanislav can attest to this) on their machines. The performance difference depends on whether external code is loaded using require with absolute path, require_once with relative path, autoload, or some mix of these. The problem requires streamlining of the loading process for files, and could perhaps be addressed by attacking the bottleneck, but is not a trivial problem to solve. Just wanted to set the record straight. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
