Re: Function caching...

Ulf Wendel wrote: > Ron Chmara wrote: > > Kristian Koehntopp wrote: > > > Jacob Verhoeks wrote: > > > > The performance problem is not with executing but with the loading of the > > > > code. We are currently developing a application server in php. That will be > > > > loaded only once. > > > 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. > > > Another problem is the setup time for large data structures, for > > > example a large network of objects representing an entity > > > relationship model by proxy or similar abstraction layers. > > PHP is absolutely, positively, the wrong place to do this. > Ron, this is an old discussions. Some think of PHP as the BASIC of the > Web, Code arrogance is meaningless. It doesn't matter what the language is, what matters is the results. Are you trying to turn PHP into C++ or Java? Does it really matter _what_ languages it's similar to, or do the results matter more? > some such as Kristian and me would like to have a little more > difficult THIS WOULD DESTROY PHP. This is the very reason _why_ PHP has been so successful, that it didn't have the unweildy code overhead of the other options. "More difficult" is bad. Very bad. > but also more performant language: (stronger) typed, This woulds break 99.9% of the code base. Many people use PHP because they want to avoid using a bondage and discipline language. > improved OO features, ... I think it's very much agreed that the current OO is less than ideal. I suggest you may avoid using it, or contribute to improving it. It's open source, so actually adding code is trivial, and you can add to your own copy, or submit changes to the official version. > WebObjects for example offers an ER model proxy and it gets used on many > high load sites. If we could rebuild such a proxy in PHP, we could > switch the underlying storage container of our applications without code > changes e.g. from LDAP to MySQL to Oci8. Abstraction of storage has it's benefits, at the cost of speed and/or features. Aolserver does this, WebObjects does this, PHP does this (with the addition of an abstraction layer). > You can't do so with the help > of the PHPLib or PEAR database abstractions. Er...You cannot write with db abstraction without using an abstraction layer, this is *obvious*. If you look into the code for webobjects, though, you still can't code for pgsql based on "cursor locations", or run a "triggered join in LDAP". My point is that the PHP tradeoff is for speed and features, and that you _can_ use a slower abstraction library, or a fast set of non-abstracted, data-source-specific components. If you use abstraction, you lose program specific features. > The possibility to switch > the storage container requires a proxy. Do we need this? Yes. We already > wrote a simple table proxy for MySQL and LDAP. More and more of our > major customers use it. Good! Did you offer to contribute an abstraction model to the PHP codebase? > > If you want speed, abstractions are the wrong approach to take. > > Scripting languages, creating abstractions, to serve over web > > pages?... ouch. Write it in C, not as objects in PHP. > Why is PIKE, the scripting language of the Roxen Webserver, faster than > PHP 4. It's not only 10, 20 or 30% faster. It all depends on what you want to do, and how you do it. Let me explain a bit of my history: I have written full applications in Filemaker Pro that went from concept to beta in three days. Why? Because it is _massively_ focused on ease of development. They sacrifice speed, SQL, expandibility, all for ease of use. This has made it a top-selling standalone DB product. It scales quite nicely to, oh, 25 concurrent users and 500K of records. :-) The tradeoffs in any system persist, and a frequent complaint about Filemaker is that a developer has outgrown the available feature set or scalability. Rather than recode and redesign, they'd like to see their favorite environment (Filemaker, PHP, VBScript) change to accomodate their needs... Completely forgetting that the ease of *use*, ease of *development*, is why they were using the tool in the first place. Not speed, not expansive features when doing XYZ, but ease of building. > It does not make sense to > write a C extension for everything. If you would do so, you would need > trained C programmers not only scripters. Right. You can also build an entire db system in Filemaker and Applescript. However, once you need more features, more speed, more options, you will *have* to redesign, and possibly switch languages, coding methods, etc. This holds true regardless of the development environment. Once you are requesting features beyond a level of scripting, you need to use *programmers* beyond the level of scripting. I think this is obvious. > And extensions introduce the > need to recompile and install a new PHP interpreter with every new > version of your extension. This is far more complicated than simply > replacing some php library scripts. Uh, if you're not used to it, yes. If you are used to recompiling PHP, it's only a few minutes. Much less than re-writing thousands of scripts to call a new library. > > Quite simply, designing applications for the web is completely > > *unrelated* to design principles for desktop applications. > > ... On a desktop, where > > it's considered OK to use 100% of the CPU for a program load, > > your object overhead will be less costly to the user. But > > on a server, with multiple users, you need to either massively > > power the server, or change the design philosophy. On a > Every complex application needs some underlying library code. Yes. How you *implement* it is the important thing. As single, small, efficient calls, or as a bloated monster call to a few hundred lines (or even thousands) of code that you may not use for the one second that the application is being used. > All large > systems I have heard of use lots of helper functions (DB abstraction, > Sessions, Permissions, lots of HTML widgets, ...). Yup. But you absolutely _cannot_ think of these calls in the same way you think of other pre-compiled languages. These aren't passive libraries where you can call 10Mb of library, and expect a pre-compiler to thow away all but four lines before compiling it once. The precompiler will still *load in 10Mb*, and it will compile it when you load a web page. Your goal is to avoid excessive compiler load, to write library calls efficiently, to compact your libraries as needed. The more you rely on outside, external, library calls, the more load time, compile time, and execution time you will suffer. If your development time is more valuable to you than your CPU and disk time, you can make that choice, and put high-speed CPU's, high speed RAIDs, high-speed servers into your system, to make up for a system that compiles at runtime (be it PHP, java, whatever). > Pentap (Till Gerken, > Tobias Ratschiller, Sterling Hughes,...) is even talking about "PentOS". > Whatever that term means, it's not going to be something small. There are tradeoffs. I'm pretty sure Till, Tobias, and Sterling have chosen ones that fit well into their design models, but may not fit well into others. It's not a question of "good" or "bad" code, it's a question of "good" or "bad" for a given set of design goals. > Of course reundant code is faster, but it's hard to change anything > afterwards. The success of abstraction really depends on how well the abstraction strategy is executed, and *likewise* with non-abstracted coding. If the code base is segmented in such a way that each page has it's own code, you cannot make global changes quickly, but per-page changes are much, much, much, faster..... it's a question of design goals. > Without abstractions you mostly end up rewriting large parts > of your applications. Development time will be longer. Any sort of methodology which focuses on execution speed *must* sacrifice development time. That's nothing new. You can use the benefits of libraries as needed, however, and _avoid_ using them when it's going to decrease performance. My development time in Filemaker Pro was so fast is would make most PHP scripters cringe, but the cost was slower execution speed and scalability. A massive abstracted db application that did the same thing would take _months_ to develop, but it could scale much better. The same trend continues all the way up to writing a custom OS for an embedded application, where it may take *years* to write and develop, but everything is executed at the maximum speed possible. So a choice has to be made between a few days, and a few years, and the many options in between. > PHP has to face the situation that our applications became bigger and > bigger over the years. You must also face the realization that you may have *outgrown* PHP, and you may need to write your own server, or change your codebase. This happens, it's part of application growth. PHP is slowly expanding in different directions, but those may not be the directions you would prefer. You are free to fork off the code and take it into your own direction, or hire a PHP developer to write custom code. > Most commercial content manangement systems or > B2B applications have a size of 40 - 100k loc (PHP code, no HTML). It depends on the system. LOC has no direct relation to features, to stability or scalability. I'm working with a massively scalable document management system that uses less than 5K loc. Every line counts, and it's *brutally* efficient. It takes much more time an effort to mainatin than it would take if it had multiple abstraction levels, but it's much quicker than doing it in an easily maintained, abstracted, way. > Would > you want to write such applications without abstractions? Abstractions are a design choice. They have great stengths, and great weaknesses. Execution speed is _not_ one of their strengths. If my goal was execution speed, I'd want to avoid them. If my goal was development and maintenance speed, I'd want to use them. *Both* choices are valid for a developer. If you have a highly abstracted environment, and wish to continue using PHP, while improving speed, you should evalute the option of reducing abstraction levels. > None of them > is using an ER modell abstraction on the pages that serve articles or > database reports because it's to slow. This is not just a PHP problem, it's an issue of design. If they coded for bare metal (say, assembly) they would have blistering speed, but it would take much longer to develop. Regardless of PHP, Naviserver, Roxen, etc. etc. > But most of them use HTML widgets > to allow easy customization and even these abstractions are too slow it > they do something more than print_table_head() etc. If you would like to perform an interesting experiment, I suggest you look into the development time with other products, and evaluate how it fits into your needs. WebObjects has some brilliant innovations, but what can be done in PHP with five lines may take 50. This is a tradeoff in *any* system. The more features you add, the slower it runs, the more abstraction layers you add, the slower it runs, but by the same token, a more abstracted system will take much less time to develop in. -Ronabop -- Personal: ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/ Work: rchmara@pnsinc.com, 520-546-8993, http://www.pnsinc.com/ The opinions expressed in this email are not neccesarrily those of myself, my employers, or any of the other little voices in my head.