PhalconPHP - High Perf PHP Framework as a C Extension | Hacker News Reader

PhalconPHP - High Perf PHP Framework as a C Extension

phalconphp.com

59 pointsbinarydreams37 comments

Even with a really complicated framework, when considering APC, I doubt that the time spent in the framework is at all significant when compared with the time required for the application itself.

They know that too probably which is why their benchmark in the embedded slides is completely meaningless (just a simple hello world)

When you switch to C for the framework code, what you gain in speed, you lose in flexibility, customizability and ease-of-deployment.

That said, a quick look at their documentation shows a nice framework that doesn't enforce too much structure while still providing the necessities that plain PHP doesn't.

It seems more likely that you'd spend more time in the framework. After all, it gets used on every single request, whereas your time-consuming app-specific code is probably only a few core pages of your site.

Then you hit the database and the time spent in the framework is all of a sudden a rounding error.

Well put, the database is usually the bottleneck in web applications, not the language or code.

A different perspective: If the database is the bottleneck in your web application, you have a problem in your code. :-)

No, you still have a problem in your database. Running a database smoothly with large datasets is the main performance problem for web applications. As fast as you can get with smart DB architecture, DB calls still take the bulk of the time compared to code running time.

I think the point is the problem isn't with the database, but with the code not cacheing results. This isn't some new problem. The database shouldn't be the problem because you should be cacheing results.

Cache is a not a solve-all solution. It is useful only for commonly used data, otherwise you just transfer the database problem to a caching problem.

If you squint, every database problem is a caching problem. The only reason we store the relations in their up-to-date form is that it's too expensive to continually replay the transaction log from the beginning of time.

Sorry, but that simply isn't true for plenty of applications, particularly if they happen to be built on relatively slow platforms like PHP, Ruby, Python, etc. That's even before we get to the bulky frameworks built on top of those!

If your data store structure and queries (SQL or otherwise) are designed to perform and scale, you can get in and out very quickly (milliseconds or less), after which you'll spend most of your time turning the data into something useful.

(That's even before we talk about caching so you don't have to talk to the data store at all...)

Facebook didn't write HipHop (and reduce CPU utilisation by 50%) because their database queries were slow!

You are using the term bottleneck incorrectly, and it's a very common error.

A bottleneck is something you get when you have multiple concurrent actions and one of them is slowing down the actions of the others. No matter how fast the other actions get, the slowest one is the bottleneck.

Framework overhead is not a bottleneck at all, it's just overhead. If your framework takes 10ms to load, it doesn't matter if your database is taking 200ms or 2ms to return it's result, you still pay the extra 10ms for the framework loading. This is because the 10ms is not concurrent with anything, you just pay it at the start regardless.

Now you can argue that the 10ms is not significant when compared to the 200ms your spending in your database, but this is an entirely different kind of argument.

Yeah I don't really see the point with your average web app requests, if anything is so intensive as for this framework to make a difference it is likely better done in the background rather than as part of a user request.

Granted it may well be good for common functions required in intensive background processes.

Probably due to the garbage SQL the framework generated for you, or the write-through cache it failed to provide.

Yes, it's true that a simple request router will probably not add a lot of overhead, whether it came from a framework or was something you rolled yourself (there's only so many ways to parse a URL). The real overhead comes from the other stuff the framework does, and chances are the heavy lifting will be in an ORM and a couple helper functions with badly written regular expressions.

Disclaimer: I haven't looked at the code for this framework, but that's pretty common among all of them.

The point of making a benchmark of a 'Hello World' is to show the overhead of a framework, compared to a simple PHP <?="Hello World"?> equivalent.

Such a benchmark, gives you a sense of how bloated/(or feature rich depending on your point of view) a given framework is, and also a rough view of the hardware resources (mainly RAM and/or CPU), which you will need to deploy a site based on it.

Thus said, it would be usefull for them to put a simple PHP baseline shown in the slides too.

As brodd says below: the moment you do something useful the percentage of time wasted by the framework becomes so small that it's in many cases not worth optimizing there.

It would still be useful to know the constant amount that the framework would add to any request. If it's 50ms, cool. If you do a hello, world and it comes out to hundreds of milliseconds, that's a lot less cool.

I can't help but think if you're willing to go this far for performance, then you'd simply choose another language over PHP (or even HipHop).

With this you loose the flexibility and transparency of having the framework in PHP. There have been many times when I've had to go routing through Zend framework to really understand how or why to do something a certain way.

Rooting. As in rooting around. Like for roots or tubers.

Routing is something Netgear and Cisco do.

That was very insightful. Thankyou.

Thanks, I think it has become habit to use 'Zend' and 'Routing' together!

Wouldn't anyone who actually needs this level of performance sooner go for HipHop? It seems like you would get better performance with HipHop and still be able to use your framework of choice.

You might want to read up on HPHP. I've found that it doesn't offer the level of performance benefits most people expect.

Also there are a number of framework features you can't use with HPHP, like autoloaders.

There is also YAF (Yet Another Framework)[1] by Laruence. It is being used at weibo.com [2].

Never tried it, but looks like a simplified Zend Framework.

[1] http://pecl.php.net/package/yaf [2] http://news.php.net/php.pecl.dev/9716

Falcon looks like a crossover between Rails and Zend. Yaf looks a little bit more zendish.

1. Opened http://docs.phalconphp.com/en/latest/reference/tutorial.html

2. Saw lots and lots of static method calls

3. Closed page again.

This way of judging frameworks has never failed me.

how's having a lot of static calls making it a bad framework?

I think that might be because people who are used to writing typical object-oriented code somehow assume that an instantiation is required before you can do /anything/.

There is nothing wrong with a static call under a lot of conditions (not stateful, no override requirements etc).

The same people also tend not to complain about C paradoxically.

Some things are just static by nature. There's no point instantiating to use their html helpers for example.

...because you can use functions and namespaces instead? (no, it doesn't make it "bad", but it's a hint that somewhere behind it there might be some overarchitectured OO monster - I admit, it's just because I'm not that much of a fun of OOP and I don't want more objects and classes than it's strictly necessary for the "backbone" of a MVC application)

* You can't extend a static method call - ie, it will always refer to a specific class, you can't replace it with another without changing a lot of calls.

* Lots of static calls are indicative of function classes - classes as namespaces for functions, and not a real OOP approach

There's nothing wrong with static calls per-se, but lots of them is a code smell in most cases.

> You can't extend a static method call

You can as of PHP 5.3 with late static bindings. `static::function()` will use the inheritance chain to find `function`

That's an inner method call, that's not the use case I was referring to. When you call a static function from a different class, you put the class name before the call, and make it different to substitute it - which you could easily if you were dealing with an instance.

Example

MyClass::func();

func() Is tied to MyClass. if you extend it, you will have to hunt down all of those calls and replace it

One trouble with judging PHP like that is that the namespace features are so very new and almost universally loathed* that classes are/were the only widely-used form of namespace encapsulation.

In a language like Python, it's not uncommon to be far more discriminating about what is a class and what is just implemented using functions. That design is lost on PHP really.

*I disagree with the loathing. The backslash is a bit ugly but life goes on.

I did spend the past hour reading through the documentation. Looks like a well-thought framework and has a couple of 'fully blown' examples. Which is good cause I hate it when I start using a library/framework only to find out hours later that its half baked.

To be honest though I'd be more inclined to use PhalconPHP for its straight-forward no-bullshit documentation and real world examples rather than the fact that its written in C.

This is something that I was thinking about a long time ago. It turns out that the gain isn't worth it because of how good the bytecode caches are.

The frameworks are slow in places because of some of the techniques used to make development faster and easier - such as autoload. autoload is notoriously difficult to bytecode cache

It isn't a coincidence that the pitch here is against frameworks in PHP and not plain PHP itself. I'd like to see a benchmark against plain PHP, I bet there isn't much of a difference.

If you really need to optimize this stuff just go into your PHP framework and rip out autoload and any fancy reflection stuff (extract, eval). Put in straight include() or require(). Use PHP for templating or a templating system that compiles to straight PHP which is include()'d. setup APC..

Saves you switching development environment, retraining developers, increasing dev time and I bet the difference in benchmarks would be pretty negligible.

The ”Number of included PHP files“ benchmark is likely flawed. In production mode Yii should use the file yiilite.php [0] which wraps most of the framework into one PHP file.

[0] http://www.yiiframework.com/doc/guide/1.1/en/topics.performa...

...whenever I see a good framework build in PHP, a part of me wants to smash the developers' heads with a double clawed hammer (just for not doing something better with their lives if not for other reasons...) (I know, I know, downvotes expected, go ahead :) )

Reply on news.ycombinator.com