Re: Function caching...

At 19:15 9/12/2000, Kristian Koehntopp wrote:

Ron Chmara wrote:

The current performance limitations in PHP come from multiple design limitations.

Keep in mind that some limitations are apache, some are the web, some are PHP. These limitations ARE. I do not care where they come from.

Well, that's a good indication that your solution is bogus. You see the limitations, you know how you want it to look in the end, so you 'throw' all of the requirements on PHP. That's plain wrong.

That buys me what? I am still running under the wrong UID. I still lose my state variables at the end of the page, including all file and network (database) handles. I am still unable to have persistent ressources, and I am still unable to share ressources among control flows as long as these flows of control are in different processes as they are in the Apache model (The current Apache model is not broken, it is very resistant against failure. The brokenness comes from the attempt to run large amounts of code inside the Apache process model instead of creating dedicated persistent code execution processes called application servers).

If you're pointing out that an application server is necessary for the UNIX environment - fine. I won't argue that. I do argue that PHP has to become this application server in its mainstream version. It shouldn't and it won't.

You have been doing small projects without much backoffice integration and much code reuse in the past, and these were not sensitive to security issues. I can think of many reasons to design applications that way, and so can Ulf, and so can the Twisd people (they worked around their setup time penalty by going to C++, but still they lose context at the end of each page).

Mind you, Microsoft's approach towards component services and application servers, at least until now, is based on stateless objects/components. They do intend to change this with .NET, though.

Going to C or C++ is not a solution, if there is a chance to have a PHP framework with a different execution model that can do the same. PHP code is much, much cheaper per line than C++ code.

Now you're talking about something different. The first important thing to realize is that PHP will *NOT* become an application server by itself, and that the way it's designed is here to stay. Not because of legacy considerations, but rather, because it's the Right Way. As I said numerous times, it doesn't prevent anyone from writing additional components, based on the same syntax&code, that would do different things. They just won't be PHP. There's a very simple rule of the thumb you have to follow, and if you do, you'll know when you go wrong. If, after any proposed changes you make are integrated into PHP, PHP becomes more complex or cumbersome to use for developing a small/medium, or even large scale applications that don't require the kind of blazing performance you're talking about - then you took the wrong turn. As I said in previous letters, the trick is to improve performance *without* impairing the strict guideline on which PHP is based, which is ease-of-use.

Done properly, an object is exact the same size as a hash, plus a single pointer to its class description. This is hardly dead-weight. Also, you need a class description listing all possible slots, and all object functions with their signatures and function pointers. You need such a class description exactly once, as it is shared between instances of that object.

Well-written OO is always slower than well-written structured code. It varies by how much it's slower, but it pretty much always is. It doesn't mean you shouldn't use objects - if they make life easier for you, to develop and maintain, use them. Buying a more powerful server costs less than hiring more developers and increasing the time to market.

Not at all. It is in fact exactly the same once you get the hang of it. That's what PHPLIB has tried to teach you for the past few years, and that's what you can learn von PHP4 sessions today, if you missed PHPLIB. Or go to Apple, have a look at WebObjects. Or go to Microsoft, have a look at ASP+ and .NET and their Visual Studio .NET if you still do not understand.

That's not quite true. The fact that companies today went after the 'hype' and made desktop applications become Web based, doesn't change the fact that the two beasts are fairly different. I personally don't think phplib was a great example of a good design. The extremely thick abstraction layers in there were never exactly my cup of tea.

Once you can keep state (using PHPLIB or PHP 4 sessions), web applications are just normal event driven applications like all others, executed in an awkward and inefficient fashion. Application servers are the means to end this awkwardness.

That's pretty much true. What *you* fail to understand, is that there are two different types of using the Web: 1. The way it was intended. 2. By forcing desktop applications into it, which then requires all sorts of ad-hoc solutions, which is where application servers come into the picture. Now, I do realize that the Web is being used today for plenty of people it wasn't designed to do. It doesn't mean that plenty, I'd even say the majority of developers doesn't use it the way it *was* intended to be used. If you modify PHP to address #2, and kill the very good support it has for #1 (which is the reason most of the people on board this list heard about PHP in the first place), you did something inherently wrong.

PHP/Zend is a commercial product. So are Java application servers. So are ASP+/.NET and Visual Studio .NET. So are Apple WebObjects.

PHP/Zend is not a commercial product. Hell, it doesn't even exist. PHP 4.0 is out there, it's an opensource projects, and it's there to stay, without any revolutionary redesigns as you suggest. Whatever products Zend Tech will come up with has nothing to do with the advancement of PHP's current path, and isn't something that should be discussed in this context.

All of them, but one, address these problems and offer solutions. Can you spot the one missing

Mind you, ASP+/.NET are still a year away, and I've yet to see an Apple WebObjects based application. So far I'm seeing the Web being comprised of mostly ASP, PHP and similar concepts, and they happen to be doing quite fine. Zeev -- Zeev Suraski <zeev@zend.com> CTO, Zend Technologies Ltd. http://www.zend.com/