

PhalconPHP - High Perf PHP Framework as a C Extension - binarydreams
http://phalconphp.com/

======
pilif
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.

~~~
siegecraft
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.

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

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

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

~~~
pytrin
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.

~~~
jasonlotito
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.

~~~
pytrin
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.

~~~
prodigal_erik
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.

------
HyprMusic
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.

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

Routing is something Netgear and Cisco do.

~~~
dpacmittal
That was very insightful. Thankyou.

------
latimer
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.

~~~
KevBurnsJr
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.

------
ppadron
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>

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

------
nikic
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.

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

~~~
pytrin
* 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.

~~~
rmccue
> 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`

~~~
pytrin
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

------
kyriakos
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.

------
nikcub
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.

------
Jakob
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...](http://www.yiiframework.com/doc/guide/1.1/en/topics.performance#using-x-9x)

------
nnq
...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 :) )

