I wrote up a very small blog post on comparing a Phalcon v1.3.1 project to a Laravel v4.1 project. You can read it here, but I will summerize and possibly go over a few things that were not covered in the post.
I started writing a personal CMS/Blog about a month and a half ago. After getting to a very basic usiblitity stand point, I uploaded to the free teir of OpenShift that I am currently using. And it failed. I am still not 100% sure why and frankly, that is a post for another time. Just about ready to pull my hair out, because of OpenShift, I move the Phalcon code out of the repo and through in a blank Laravel 4.1 install. It worked, so... I went with it. I like Laravel and have used it on another project, but I did not want to use it for this one. But I really had no choice at this point and what you see from the link above is that site.
This past weekend, I decided that I would catch the Phalcon project up to were the Laravel project currently is, plus make sure everything will still work as expected with 1.3.1. So after doing this, I decided to use WebGrind and check out the performance different between to the two projects sitting on my local machine. Reason? I just wanted to know, for one, but also you could actually see a different in how the pages load. I wanted to make sure that I had not messed up some CSS (there's almost no JS libraries in use. Outside of Disqus, which is not intergrated into the Phalcon post views, and Google Analytics which again, is not in any of the Phalcon layouts). Well, here is what I found...
Laravel v4.1
Running a simple query that retrives all of the posts and displays them in orde of their 'id' in a view -
-
Functions Executed : 961 different functions
- Time to execute : 2050ms
Phalcon v1.3.1
Same as above. Exactly the same
-
Functions Executed : 57 different functions
- Time to execute : 70ms
Sceenshots are avaliable in the blog post, soo I did not feel a need to duplicate that here.
Now, I knew there was going to be a difference. But I had no idea there was going to be that much difference! My jaw hit the floor when I saw those numbers! So tonight,
Right off we notice a big difference in Time to Execute. This is most likely a reflection of my "cache" at that time or possible my drive was doing something at the time of the first test. Oddly it seems, at first glance, that the weakest link or most expensive is Composers autoloading. I would suspect that trugging through what looks like 36 different files and getting them loaded into the application is quite the task, but no. What is not done justice in the screen shot in my Laravel example screen shoft is that upon reordering the 'Total Inclusive Cost' column, shows that Illuminate\Foundation\Application->run() , Illuminate\Session\Middleware->handle(), as well as Illuminate\Routing\Router->dispatchToRoute takeing up the largest chunk of the chug-a-luggin. All scoring above 50.0. To better display this, I re-ran the tests and found that the Laravel site was actually performing a bit better. Also, I re-orgizined totals a bit to better show what processes were displaying the most cost. What follows is a screen shot of that test...
In our Phalcon example of the app, we can see that similarly to Laravel php::Phalcon\Mvc\Application->handle() is a heavy hitter in the performance catagory, but coming in a fluffy 20.68 just does not compare to Laravels 65.53 TIC (Total Inclusive Cost).
In all fairness, I am not bashing on Laravel just for the sake of bashing on Laravel. Laravel has it's place in the PHP community and will be a big player in the community for a long time to come. I would also expect to see these same numbers from the likes of Symphony or ZendFramework as well. They are all big. They are that way for a reason. But it is Phalcons approach to PHP, as an extention, that single handedly allows it to over shadow the other frameworks out there today, from a performance stand-point. I would really like to see some numbers comparing Laravel 4.1, running on HHVM, and compare those to a pure Phalcon installation. Interesting! Now those numbers might be more in line of what I was actually expecting to begin with.
Again, for the actual code being used in each and more screen shots, check out the blog post linked to at the top of this post. I am currently in the process of getting a Vagrant workflow going that is hooked up to a New Relic account, so I will be performing more in-deth tests at a later time.
