Omega Framework 0.9.0 Available

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

cwis
Forum Newbie
Posts: 8
Joined: Tue Oct 02, 2007 5:54 pm

Omega Framework 0.9.0 Available

Post 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!
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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!
(#10850)
cwis
Forum Newbie
Posts: 8
Joined: Tue Oct 02, 2007 5:54 pm

Directories

Post 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
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
cwis
Forum Newbie
Posts: 8
Joined: Tue Oct 02, 2007 5:54 pm

Post 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).
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post 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.
cwis
Forum Newbie
Posts: 8
Joined: Tue Oct 02, 2007 5:54 pm

Post 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.
User avatar
Kieran Huggins
DevNet Master
Posts: 3635
Joined: Wed Dec 06, 2006 4:14 pm
Location: Toronto, Canada
Contact:

Post 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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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?!
(#10850)
cwis
Forum Newbie
Posts: 8
Joined: Tue Oct 02, 2007 5:54 pm

Post 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.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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.
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post 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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
cwis
Forum Newbie
Posts: 8
Joined: Tue Oct 02, 2007 5:54 pm

Post 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
cwis
Forum Newbie
Posts: 8
Joined: Tue Oct 02, 2007 5:54 pm

Post 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.
Post Reply