Page 1 of 2
Omega Framework 0.9.0 Available
Posted: Tue Oct 02, 2007 6:14 pm
by cwis
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!
Posted: Tue Oct 02, 2007 10:13 pm
by Christopher
Arrrr ... If ever there be a code base that be screamin' t' be organized-like in some of them there sub-directories -- ahoy there it be!
Directories
Posted: Wed Oct 03, 2007 1:31 am
by cwis
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
Posted: Wed Oct 03, 2007 3:19 am
by Christopher
I don't see how putting all the files in one directory would help performance. Nor do I see how putting everything into one file and loading it whether it is used or not would help performance either.
Posted: Wed Oct 03, 2007 3:13 pm
by cwis
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).
Posted: Wed Oct 03, 2007 3:34 pm
by RobertGonzalez
I am getting a 403 forbidden error when trying to browse the repository or SVN checkout the codebase. I would rather not download it and unpack it.
Posted: Wed Oct 03, 2007 3:40 pm
by cwis
Everah wrote:I am getting a 403 forbidden error when trying to browse the repository or SVN checkout the codebase. I would rather not download it and unpack it.
Oops, my fault. Should be fixed now.
Sorry for the inconvenience.
Posted: Wed Oct 03, 2007 4:12 pm
by Kieran Huggins
I was thinking along those lines a year or so ago, but XML+XSL finally broke what remaining sanity I had left into tiny little pieces.
XML can bite The Big One, IMO.
Posted: Wed Oct 03, 2007 4:37 pm
by Christopher
Yes, but you are comparing including all the files individually to including everything packed into one file -- of course it is faster. But when would a request include all 150 files in a framework?!
Posted: Wed Oct 03, 2007 5:00 pm
by cwis
arborint wrote:Yes, but you are comparing including all the files individually to including everything packed into one file -- of course it is faster.
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:But when would a request include all 150 files in a framework?!
No single request include all 150 files, of course. Here are your options:
- 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().)
My point is that since option two is *way faster*, there is no reason not to use it on a production environment.
Posted: Wed Oct 03, 2007 6:20 pm
by Ambush Commander
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.
Posted: Wed Oct 03, 2007 7:10 pm
by RobertGonzalez
I will be looking over the code and architecture of the framework over the next few days. If I have anyting valuable to add in terms of comments, I will do so.
Posted: Thu Oct 04, 2007 12:37 am
by Christopher
I tried it on PHP 5.2.4 and could not get it to work. There were a couple of classes redefined. FYI it does not work on pre-5.1 because it needs RuntimeException. And it is not very Unix/CLI friendly with those spaces in directory names.
Posted: Thu Oct 04, 2007 1:46 am
by cwis
arborint wrote:I tried it on PHP 5.2.4 and could not get it to work. There were a couple of classes redefined.
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.
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
Posted: Thu Oct 04, 2007 6:15 pm
by cwis
cwis wrote:I'll have to fix this!
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).
Everything should now work as expected. Please do not hesitate to get back to me if you need anything else.