HipHop - Something to Keep an Eye On

This has been reported for a few days now, but Facebook just announced and will hopefully soon release HipHop for PHP, what looks to be a PHP compiler that analyzes, optimizes and compiles PHP code into C++ which can then be run on the HipHop webserver.

It's obviously designed to increase efficiency especially for heavily used applications... and overall it's a very compelling project.

The HipHop PHP interpreter is designed on the 5.2 PHP Language “with a few features taken out”... which means it would be interesting to see what kind of compatibility issues there could be with Qcodo.  Depending on how HipHop evolves, I could see a tremendous advantage in supporting Qcodo on HipHop, but I think we'll have to see.

I'll definitely be keeping my eye on the project... meanwhile, I'd love to hear any thoughts that folks might have.

As a FYI, there is a quick write-up on this on developer.com.

For those that are curious, Facebook held a Technology Tasting talk which can be viewed online...

It looks pretty promising -- as Simon posted above, we may need to rethink QDataGrid, specifically, as it uses eval().  QCodeGenBase also uses eval() to perform the actual code generation of your ORM, but since that's obviously done during development and NOT at runtime, that shouldn't really be an issue at all.

I'm happy to hear that they do offer support for magic methods which Qcodo utilizes a lot -- I'm curious to see if it's truly 100% compatible as well as looking at performance improvement numbers between hiphop and interpreted PHP...

Simon, I wonder if you can shed some light specifically as to any performance issues that you're seeing in real world production -- I see posts on occasion where folks are seeing performance issues, but when I ask for follow up on which aspects they are seeing performance issues with, I either get folks that bring up theoretical problems (e.g. use cases which cause slow down but aren't actually seen in production environments) or I get very little further information, thus making improvements very difficult to come by...

Have you been able to perform any profiling on your application to see what specifically is causing poor performance?

I know of several higher-traffic sites like uloop.com and chess.com which I'm told get anywhere from 5-10 million rendered page views per month, with bursts of up to 100+ concurrent connections, served on minimal (e.g. 2- or 3-VM) server infrastructures with little to no issues.

On occasion I come across folks that have performance issues, but after profiling, we realize that the issue is either as simple as a missing MySQL index or just an optimized QQuery call, and that would largely alleviate the issue.  Once in a while, it's a bit more complex of an issue where some data model refactoring is involved -- but either way, it's an issue at the application level and not necessarily at the framework level.

Please note I am not saying that the framework doesn't have its inefficiencies -- I'm sure it does. =)  But what I am saying is that in order to be able to make concrete improvements to this, it would be great to get some quantitative and/or qualitative data points on what is inefficient and perhaps even suggestions on how those areas could be improved...

I'd be curious to hear more thoughts.

Ah yes -- i apologize but you're right.  This is definitely another area where I have found some applications struggling with performance.

Yeah, QForms isn't designed well when having over 100 or 150 simultaneous QControls on a page... so having 400 would definitely have performance implications.

But on the flip side, oftentimes a page can be redesigned technically to bring down the total qcontrol count down to a manageable size, often through the use of things like QControlProxy and more-dynamic creating/destroying of qcontrols during the life of a page.

For example, if you have a datagrid with an “edit” button on each row of the datagrid, then the “Edit” button could be converted into a standard HTML button, and all these HTML-only buttons can utilize a single QControlProxy to manage events/tasks.

So if you have a page with a datagrid with 50 rows, each with its own button, you've just essentially cut down the count of qcontrols on that page by 49.

And this is just one of quite a few relatively simple ways that a page can be modified to lighten the qcontrol count which can hopefully significantly lighten the weight of the form state as well as lighten the server load.  Feel free to post with any questions, concerns or comments.