Omega Framework 0.9.0 Available
Moderator: General Moderators
Omega Framework 0.9.0 Available
Hello everyone,
I am pleased to announce the release of Omega Framework 0.9.0. This new framework, built for PHP 5 and licenced as GPL software, mimics the features found in other popular frameworks such as Symfony or Ruby on Rails. Its main features are a very powerful data access layer, a strong caching system, compatibility with web standards such as Ajax, XML and XSL and an exhaustive documentation.
Home page for this project is http://www.omegaf.org. You can take the tutorial, browse the documentation, or see why we think this is better than Symfony.
Of course, the Omega Framework is just at the beginning, and we need your help: if you have some time to spend, you are invited to get your copy and give us your feedback.
See you soon!
I am pleased to announce the release of Omega Framework 0.9.0. This new framework, built for PHP 5 and licenced as GPL software, mimics the features found in other popular frameworks such as Symfony or Ruby on Rails. Its main features are a very powerful data access layer, a strong caching system, compatibility with web standards such as Ajax, XML and XSL and an exhaustive documentation.
Home page for this project is http://www.omegaf.org. You can take the tutorial, browse the documentation, or see why we think this is better than Symfony.
Of course, the Omega Framework is just at the beginning, and we need your help: if you have some time to spend, you are invited to get your copy and give us your feedback.
See you soon!
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Directories
Hello arborint,
All PHP files were located in the same directory because of performance reasons. However, since OF is using the BigOne, there's no such reason anymore.
Cheers,
--
cwis
All PHP files were located in the same directory because of performance reasons. However, since OF is using the BigOne, there's no such reason anymore.
Cheers,
--
cwis
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
In an ideal word, this should not make any difference.
However, in the real world, access to the filesystem can be a time-consuming operation. Splitting your PHP files into several directories means that, each time you do an include() with an unqualified path, PHP looks in each include_dir directory if the file exists. Since the Omega Framework has about 150 files, wasting a few milliseconds each time one needs to be included means wasting a lot of time in the whole.
Second, the PHP parser is far from being the most efficient parser available today. The Big One file you are talking about addresses two issues: the first is the time needed to search files within include() calls, the second is related to shortcomings of the PHP parser. The BigOne.php file is constructed in such a way that it is extremely fast to parse.
That being said, I am not inventing my figures. I invite you to profile this fact by yourself. I did with XDebug, and my results are as shown (Pentium IV 2.6 GHz, IIS, PHP 5.2.4):
- preventing include() by using a single file saves ~20ms;
- formatting the BigOne as does Omega Framework saves ~30ms (from 30ms to 0.2ms, that's a 100% speed improvement!).
IMHO, saving 50ms makes perfectly sense, even if this is not particularly intuitive how to do so (remember, you can -- and should! -- turn the BigOne off while developping your app; there's a define() in Omega/Omega.php for doing exactly that).
However, in the real world, access to the filesystem can be a time-consuming operation. Splitting your PHP files into several directories means that, each time you do an include() with an unqualified path, PHP looks in each include_dir directory if the file exists. Since the Omega Framework has about 150 files, wasting a few milliseconds each time one needs to be included means wasting a lot of time in the whole.
Second, the PHP parser is far from being the most efficient parser available today. The Big One file you are talking about addresses two issues: the first is the time needed to search files within include() calls, the second is related to shortcomings of the PHP parser. The BigOne.php file is constructed in such a way that it is extremely fast to parse.
That being said, I am not inventing my figures. I invite you to profile this fact by yourself. I did with XDebug, and my results are as shown (Pentium IV 2.6 GHz, IIS, PHP 5.2.4):
- preventing include() by using a single file saves ~20ms;
- formatting the BigOne as does Omega Framework saves ~30ms (from 30ms to 0.2ms, that's a 100% speed improvement!).
IMHO, saving 50ms makes perfectly sense, even if this is not particularly intuitive how to do so (remember, you can -- and should! -- turn the BigOne off while developping your app; there's a define() in Omega/Omega.php for doing exactly that).
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I agree this ought to be faster, but *that* faster? On a script previously executing in 100ms, I gain 50ms with just this technique. Seems a lot to me.arborint wrote:Yes, but you are comparing including all the files individually to including everything packed into one file -- of course it is faster.
No single request include all 150 files, of course. Here are your options:arborint wrote:But when would a request include all 150 files in a framework?!
- Option one. You include() the files you need. (Let's say you follow the standard way of putting one class per file, so that you can use auto-loading. If your script needs 30 class, then it will need 30 include().)
- Option two. You include() one file which already consists of all the 150 files. (This way, no more autoloading, no more overhead caused by include().)
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
My experience confirms what cwis has observed, and my library HTML Purifier offers a "single-file" version of the library. For a very tightly integrated library, this is invariably benefit, since most of the classes end up being used anyway; and one doesn't have to include the library at all if it's not necessary.
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Oops, the BigOne script generation did not work as expected on the Unix machine used to generate the release ZIP file. (It failed to guess the dependancies between the Collection class and other classes from the framework, hence it failed to put Collection on top of the dependant BigOne.php file.) That's weird. I'll have to fix this! In the meantime, I have released version 0.9.1 which fixes this glitch. You can get it on http://www.omegaf.org.arborint wrote:I tried it on PHP 5.2.4 and could not get it to work. There were a couple of classes redefined.
If you already downloaded 0.9.0, you can fetch the correct BigOne [url=http://www.omegaf.org/download/0.9.1/BigOne.php.zip]here[/ur].
Sorry for the inconvenience and thanks for noticing,
--
cwis
FYI, fixed in version 0.9.2. There was a problem with the script which generates the BigOne. Let's suppose you have class B which extends class A and implements interface I and J, and you have class D which extends class B. In this case, the script must generate the BigOne so that the interfaces come first, then class A, B and finally D (because base classes and interfaces must appear first). There was a bug when some of the dependancies have been output in the BigOne.php, but not all of them (for example, class B could appear after class A but before interface I).cwis wrote:I'll have to fix this!
Everything should now work as expected. Please do not hesitate to get back to me if you need anything else.