Could someone tell me why Java is faster than PHP

[Ren]

You can easily run a small command-line app with less than 4MB of RAM in java. Java doesn't use a lot of memory...it does take awhile to start up. But if you have any evidence that PHP uses less memory than Java reference it.

What the hell are you even talking about? In java any code that becomes "hot" will be compiled to native code. Whether that code is running a web application or desktop app simply doesn't matter.

google.com - Anybody that denies that Java as a language is faster than PHP is a mindless fan-boy of PHP. ...hell try writing any NON-TRIVIAL algorithm in PHP and Java and see which which does better. PHP can solve some of its performance problems by outsourcing its work to C via an extension though. PHP is just not in the same class as Java, compare it to Perl, Python etc.

But what exactly non-trivial algorithms do you need in a web enviroment ?
99.99% is get data from here, apply some fairly trivial rules, and put it there.
We aren't solving the travelling salesman problem, or anything close to being non-trivial imo.

Adding typing information to variable names makes things really ugly.
Furthermore if you have to add typing information to the variable names and/or document how does this imply less work?

This seems to be rant against Hungarian notation, and nothing todo with any language.

Have you actually worked with java web applications AT ALL? Please tell me why you can't "add more hardware" to java applications? EVEN if you wrote an application that is not distributable you can easily cluster tomcat (or any other servlet container) using sticky sessions. This is almost trivial to set up. Need more power? Add another tomcat instance. If your application was written to be distributable then its...a no-brainer...and ahem if you are working on the sort of app that can't run on just one server....you'd do that. But more importantly....the part of scalability that is being talked about in this post is that of the code. PHP's code is not scalable.

I've been involved with companies that run high end sun fire servers, using off the shelf software (from BEA) and they had huge scalability problems. The GC basically was broke, and resulted in running out of memory. The solution was to double the amount of memory per server so they didnt have to power cycle as often.

Large web applications have thousands and thousands of source files being worked on by many people....there is no sensible way to manage this with PHP.

I don't see how its any different from managing thousands of java files.

[DerelictMan]

Dynamically typed languages have many advantages that statically typed ones do not.

And vice versa...

Data type indicates absolutely nothing about a variable.

Nothing? Of course there are many intelligent people on both sides of the static vs. dynamic typing issue, but usually the argument made by the pro-dynamic typing people is that static typing does bring benefits, but it also brings costs and they feel the costs outweight the benefits. But I don't usually see too many people who say that data types provide no information at all, a statement that seems a bit hyperbolic to me.

I'll agree that in simple web apps it probably doesn't make much of a difference whether you're dealing with an integer 1, a string "1", or a double 1.000. Primitive types can be fairly easily coverted to other primitive types without losing too much information. However, in object-oriented code I've found data type information to be highly useful. Consider two random classes that you use in your PHP code. It's not very likely that an instance of one of your classes could be converted to an instance of another... the class of a particular variable is very important, and indicates what it is and what can be done with it (what methods can be called, etc.). It seems odd to say that this information doesn't matter.

Use sensible variable names and document your code or it'll be hard to use.

For me, one of the advantages (and yes, I see disadvantages too) of static typing in an OO language is documentation. It's immensely useful to know without a doubt what type of objects are required as parameters on a method, and what type of object I'm going to be getting back. I've found in my and other's dynamically typed OO code, there is sometimes a tendency to give object instances longer and more cumbersome names in an effort to make it clear what class the instance belongs to. This is, in a way, a type of Hungarian notation for types, and I think most people here would agree that this is a Bad Thing. Sure, you don't have to do this; you can pick the same names as you would in a statically typed language, but it sometimes makes it a little trickier to know what you're dealing with, especially if you have classes that are different but may contain a common subset of similar or the same method names.

Forcing something as archaic as static typing on web development slows development cycles painfully.

I think it depends on what style works for you. A counter argument to this is that it may slow initial development time, but it may improve maintenance time. You only write your app once, but you may be refactoring/maintaining it for a long time to come. The argument could be made that you should optimize for maintenance and not for the initial development time.

As for me, I see advantages and disadvantages to both. For simple tasks, static typing can be onerous. For more complex ones, I feel it improves the ability to reflect on what the code is doing and it may improve maintenance. So, speaking for me personally, I don't necessarily prefer one over the other; they both very much have their uses.

PHP excels as a web app language and as a general-purpose scripting language.

You are being slightly inconsistent here. You say that PHP excels as a general-purpose scripting language. But earlier in your post you stated:

Fast garbage collection is meaningless when you simply toss away the entire app context at the end of the request (the way that you build PHP apps). PHP's garbage collection is actually pretty terrible, but it doesn't matter because you just toss it all out at the end of the request.

I don't see how a platform that has "pretty terrible" garbage collection can possibly excel as a general-purpose scripting language. "General-purpose" means that you may not be dealing with short-lived requests and environments that are being tossed out rapidly. I would argue that PHP does excel as a web app language but still has some improvements to be make before it can truly be "general-purpose".

It can replace perl for everything

I beg to differ. Perl most definitely has its warts, but it's still very useful for many tasks. PHP does not currently, and likely never will, have anything comparable to CPAN. You may find Perl the language ugly (although in many ways it is much more advanced than PHP: true block-level scoping, namespaces, closures and truly-anonymous code blocks, etc.), but there is an amazing selection of truly-useful reusable code available at CPAN for just about any task you can imagine. I've found that the same cannot be said for PHP. My personal opinion is that the lack of namespaces in PHP makes encapsulation at a library-level difficult and discourages the development and sharing of generic classes and class libraries.

Disclaimer: I've been pretty down on PHP in this post. Before anyone gets the idea that I'm a "hater" let me state that I do think PHP has a sweet spot in certain types of applications, and I use it heavily where it makes sense. It just feel that this attitude of "PHP has nothing to learn from other platforms" holds it back, and that's a shame...

Off Topic:

EVERY language is "compiled".

Actually, I've seen it stated that Ruby scripts are currently not compiled to bytecode/machine language, but are converted into an abstract syntax tree and interpreted. So, it could be argued that Ruby isn't compiled.

[Selkirk]

PHP's garbage collection is actually pretty terrible

Can you prove this.

PHP uses a simple, naive reference counting algorithm for garbage collection. The link discusses the pros and cons of that.

[Snaily]

But what exactly non-trivial algorithms do you need in a web enviroment ?

If you are using PHP for just a thin web client then it works great, as everything is as you say. But many web applications need to do non-trivial work, for example any sort of AI in the application (and yes many web apps use such) or even things like caching algorithms.

This seems to be rant against Hungarian notation, and nothing todo with any language.

The point of the comment is not a rant against Hungarian notation, rather to say that you have to do the same amount of work when you use hungarian notation vs using a OO language with static typing. That is to say the argument that languages with static typing take more "work" is silly.

I've been involved with companies that run high end sun fire servers, using off the shelf software (from BEA) and they had huge scalability problems. The GC basically was broke, and resulted in running out of memory. The solution was to double the amount of memory per server so they didnt have to power cycle as often.

So basically you threw hardware at the problem. But really if it was eating up memory like that, that is a good indication that there is a memory leak in the application...did see what was eating up all the memory? Were any efforts made to find memory leaks in the application? Usually companies don't bother with this stuff...as memory is so cheap. But don't blame java for a company that doesn't want to find memory bugs in their application.

I don't see how its any different from managing thousands of java files.

Then you aren't thinking hard... THere are many reasons most notably that PHP lacks namespaces.

[Dr Livingston]

Even without Namespaces though, PHP still has credible functionality in regards to files, particularly with PHP5. Lets not forget that PHP has far greater grace than Java when strings and arrays are involved, particularly, this benifit comes from the core root where PHP comes from.

Both technologies have their advantages and disadvantages, so use the one which is best suited to the task... Why argue about what amounts to be, trivial technicalities?

[Snaily]

Even without Namespaces though, PHP still has credible functionality in regards to files, particularly with PHP5.

I'm not sure what you are talking about here, explain?

Lets not forget that PHP has far greater grace than Java when strings and arrays are involved, particularly, this benifit comes from the core root where PHP comes from.

This is a mere aesthetic matter...it may be your view which is fine, but don't pretend as if its universal. I certainly don't agree with it.

[DerelictMan]

Lets not forget that PHP has far greater grace than Java when strings and arrays are involved, particularly, this benifit comes from the core root where PHP comes from.

PHP's arrays are not universally loved. The way that PHP conflates arrays and hashes is frequently cited as a problem and can sometimes violate the principle of least surprise. Some may see it as an advantage, but it brings its problems as well. For example, when dealing with arrays that may come from unknown sources (say, a POST or GET request), the following code isn't safe:

<?
if (count($someArray) == 1) {
  doSomethingWith($someArray[0]);
}
?>

You cannot know for sure that just because the array only has one element that you can refer to it with the 0 offset. It could be anything. Sometimes you WANT an array to be an array, and not a hash, but you don't get to make that choice in PHP. Sure, you can sanitize the array's upon input and rebuild them to reorder the keys, but then you have to worry about which you want to treat that way and which you don't. Sometimes it would just be easier to be able to be explicit, I think.

Both technologies have their advantages and disadvantages, so use the one which is best suited to the task... Why argue about what amounts to be, trivial technicalities?

I agree with this.

[bonefry]

For those who say Java uses a lot of memory ... think about mobile applications.

JAVA beats the living crap out of PHP, when it comes to performance, for the following reasons:

1) The Hotspot JVM knows about "adaptive optimizations" ... something that even the .NET CLR doesn't have yet

2) PHP, being so crapy, is recompiled at every request, so that Zend can make a living

3) The cost of a new process is higher than the cost of a new thread

4) The JAVA language can be optimized very efficiently because it is a static language

5) A LAMP setup doesn't have stuff like connection-pooling by default


For those who say that PHP is more scalable that JAVA ... PHP is scalable because of its mediocrity ... and tell me ... what infrastructure does PHP provide for distributed applications ?



Anyone that says otherwise is clearly wrong, ignorant or religios about it.

This thread is useless as it clearly leads to a flamewar ... because of fan-boys that can't accept the limitations of a scripting language ... and thus they bash a technology they do not use or know.
If you want productivity, then PHP may be the answer for you, but if you want performance ... with PHP it is like looking against the SUN

[bonefry]

BTW, namespaces, strings, arrays, or all other syntax advantages or dissadvantages of PHP have nothing to do with its ability to scale.

In fact, PHP cannot scale too well precisely because of its shared-nothing architecture, and because the platform is crippled because of ZEND trying to make an honest buck.

Lets not forget that PHP has far greater grace than Java when strings and arrays are involved, particularly, this benifit comes from the core root where PHP comes from.

Actually, have you worked with the collections framework in JAVA ?

Compared to the collections in JAVA, or with the Array in Ruby ... PHP's structures are hidious.

[timvw]

Something i hate more and more about PHP: Virtually every webhost is using a different php.ini and they all have different extensions in use... Some use mod_safe, most don't. Some have enable short tags, most don't.. With Java you know what you can expect if you know which version your webcontainer supports...

[Ren]

If you are using PHP for just a thin web client then it works great, as everything is as you say. But many web applications need to do non-trivial work, for example any sort of AI in the application (and yes many web apps use such) or even things like caching algorithms.

Still 99.99% is trivial as I said originally. Complex things like data mining don't get performed in a web enviroment.

The point of the comment is not a rant against Hungarian notation, rather to say that you have to do the same amount of work when you use hungarian notation vs using a OO language with static typing. That is to say the argument that languages with static typing take more "work" is silly.

So basically you threw hardware at the problem. But really if it was eating up memory like that, that is a good indication that there is a memory leak in the application...did see what was eating up all the memory? Were any efforts made to find memory leaks in the application? Usually companies don't bother with this stuff...as memory is so cheap. But don't blame java for a company that doesn't want to find memory bugs in their application.

The software vendor was involved in the solving the issue. The issue was the Sun Java VM GC, not the software.

Then you aren't thinking hard... THere are many reasons most notably that PHP lacks namespaces.

Namespaces are not a problem. PHP can have namespaces, as several patches have demonstrated.

[Snaily]

BTW, namespaces, strings, arrays, or all other syntax advantages or dissadvantages of PHP have nothing to do with its ability to scale.

Why wouldn't they? Part of what makes a application scalable is its ability to deal with large development teams, large code bases etc. Which language used clearly effects this... But often when people say "scaling" they are referring to performance issues etc in this context yeah.

2) PHP, being so crapy, is recompiled at every request, so that Zend can make a living
3) The cost of a new process is higher than the cost of a new thread
5) A LAMP setup doesn't have stuff like connection-pooling by default

These points are not very applicable... #2, there are many free opcode caches for PHP, they are trivial to install. #3 This is an apache issue...PHP doesn't create threads or processes, that work is left to apache and can be done either way with apache 2.0+.
#5 Depends what you take the P to mean...connection pooling can easily be done with Perl.

Still 99.99% is trivial as I said originally. Complex things like data mining don't get performed in a web enviroment.

Your point is just myopic. Please look at what it takes to implement a regular expression engine (and regular expressions are used ALLLL over the place in web apps). When you start writing non-trivial web applications you'll find that there are no longer PHP extensions to do all the hard work for you.

Namespaces are not a problem. PHP can have namespaces, as several patches have demonstrated.

Namespaces are a language feature...PHP lacks them. Please explain which "patches" you are referring to.

[Ren]

Your point is just myopic. Please look at what it takes to implement a regular expression engine (and regular expressions are used ALLLL over the place in web apps). When you start writing non-trivial web applications you'll find that there are no longer PHP extensions to do all the hard work for you.

I know what it takes to implement regular expressions. From simple Henry Spencer style recursive descent, to the more complex NFA/DFA systems for grep. Perhaps you should look at my post history, posts like implementing LALR(1) parsers in PHP.

Namespaces are a language feature...PHP lacks them. Please explain which "patches" you are referring to.

Few of them are at http://www.phpnamespaces.org/wiki/

[Snaily]

I know what it takes to implement regular expressions. From simple Henry Spencer style recursive descent, to the more complex NFA/DFA systems for grep. Perhaps you should look at my post history, posts like implementing LALR(1) parsers in PHP.

Because I don't care about your post history. So great you know what it takes...and you know they are used in web applications...but web applications only use non-trivial algorithms. RIGHT! Also writing a parser in PHP seems so silly...due to its performance issues...unless of course you needed such for a web application....but that couldn't be so right?

Few of them are at http://www.phpnamespaces.org/wiki/

Well the site clearly states why php should have namespaces...but they don't offer a solution they offer ideas on how a solution would look like. I mean they clearly state what they are doing is for demonstration. Namespaces are the sorts of things that need to be added to the language itself.

[sumanpaul]

i really dont know much of programming stuff, just write simple PHP websites for my down to earth clients. Trying to learn Java so that I can get a job.
Now I read almost all replies. I cannot add much to this thread as I dont know!

But just one question ... is Java and PHP comparable?
similerly is it fare to compare Zend Vs. SUN?

I am not sure this post can add any new thing to this increadebily informative(though with a sense of fire) thread. Moderator please delete this post if needed.

[Fenrir2]

Actually, I think this is wrong. The two main issues that come to mind are that PHP lacks namespaces and that PHP is dymanically typed. The first I think most would agree with. With the second you can add comments to variables, methods etc to give hints about what they are suppose to be...but this is a bit hacky and usually developers get lazy with documentation. Also I'm aware of PHP5's "type hinting" in methods, but this only solves a few of the problems.

Static typing is BAD if speed isn't your #1 goal. And if it were, you would use C. Static typing can be good for languages like haskell, in which the compiler infers the types. In Java, it's the human compiler at work.

Adding typing information to variable names makes things really ugly. Furthermore if you have to add typing information to the variable names and/or document how does this imply less work? You do the same work the difference is languages with static typing can use this information at compile time. Furthmore good IDEs in Java do all the typing work for you. Have you actually worked on a proejct with more than 50 files to manage?

You shouldn't care too much about types. It's come from old languages where speed was needed. The ide's don't do all the work, plus, it's not only about writing and keystrokes, it's also about reading. You'll write code once, you'll read it many times (if it's not a throwaway program). Types in code you read = garbage => it slows you down.

I think it depends on what style works for you. A counter argument to this is that it may slow initial development time, but it may improve maintenance time. You only write your app once, but you may be refactoring/maintaining it for a long time to come. The argument could be made that you should optimize for maintenance and not for the initial development time.

What happens if you want to rename a class? Static typing is obviously bad for maintainance.

Prove that Java is "faster" than PHP in the general sense. "I think PHP is faster because of x" or "I think java is faster because of Y" doesn't work. Make two applications that run similiar logic and test them by sending several hundred simultaneous requests at each. Come back and report the results.

according to the complang shootout, Java is ~15 times faster than ruby, but uses ~5 times as much memory.

There was a presentation of ruby on rails. One rewrote his java app in ruby, and guess what? It was faster. With several caching metods, the speed advantage was 100-1000% (!). For highly dynamic websites, caching is no option. The speed advantage without caching was still 10-20%. The code was much shorter. The entire application in rails was about the same size as the xml configuration file of the java one.

You can still say that the Java version could have been made faster with caching. Example: you have 2 months to create an application. Because ruby code is much shorter, and faster to write, you have finished the ruby version in 3 weeks. You then have more than one month to set up caching . You java app has cost you 1.9 months. No time to set up caching. In the end, the ruby one is faster. ;-).

What this means is that 1. the one who wrote the app was much better in ruby, even though this was his first ruby app. Or 2. he had to get around the limitations of the static java language, this made code huge, and slow.

[Ulchie]

I do not program so I am not qualified to write this. I'll write my view on the matter from a non technical web surfers perspective.

Half the time php pages loud fast enough that I wouldn't know its in php. I ALWAYS know if its JAVA because the damn thing takes a little while to loud the java applet. After the applet is louded it works fine and is fast though. But I hate waiting for the damn thing to load in the first place. I want the information now, not in 10 seconds. Java also seems to use more of my system resources that a php application does... I don't always like that. Sometimes I might have 15 windows open including a few programs, lots of web sites, a music program, and some of those damn pdf files. Then you get another page that is java based... just what I needed, more resource drain.

But what do I know? I'm just the non-technical end user.

[Ren]

Because I don't care about your post history. So great you know what it takes...and you know they are used in web applications...but web applications only use non-trivial algorithms. RIGHT! Also writing a parser in PHP seems so silly...due to its performance issues...unless of course you needed such for a web application....but that couldn't be so right?

Hmm that makes no sense. And the parser wasnt for a web application.

Well the site clearly states why php should have namespaces...but they don't offer a solution they offer ideas on how a solution would look like. I mean they clearly state what they are doing is for demonstration. Namespaces are the sorts of things that need to be added to the language itself.

Yes, due to the open source nature the differing patches get evaluated for inclusion into PHP language.

[DerelictMan]

What happens if you want to rename a class? Static typing is obviously bad for maintainance.

The only thing that is obvious is that you have no experience with modern statically-typed languages, and are speaking from ignorance. Static typing makes renaming classes, methods, constants, etc. easier because tools such as IDEs can perform static analysis on your code and know 100% that all references have been updated. Try a modern IDE such as Eclipse. It has refactoring tools built-in that do things like renaming classes, methods, variables, packages, etc. In Eclipse you select an identifier, hit ALT-R, type in the new name, and you are done. ALL references in your project are updated automatically. No regular expression search and replaces required. And this is possible precisely because of the information that static typing provides the tool.

Dynamically typed languages make such refactorings much more difficult. Sure, you can use regex search-and-replaces (I do it all the time with my PHP code in jEdit) but you cannot be gauranteed that all references were updated. (I know, I know, that's what unit testing is for.) Tools cannot automatically handle this for you because it's impossible to know where all the references to the code you want to refactor are without actually running the application and hitting all conditionals/branches/etc. Since PHP (and other dynamic languages) allows you to store the names of classes, methods, etc. as strings and invoke them that way even the most inclusive regex can't gaurantee that all references are updated.

Besides simple renames, Eclipse (and other Java IDE's) provide support for other refactorings including "extract method", "inline method", "extract interface", etc. Simply put, if you have never used a modern IDE with a statically typed language such as C# or Java then you have no idea what static typing makes possible regarding tool support. There is simply no analog to this in the PHP world.

[Selkirk]

1) The Hotspot JVM knows about "adaptive optimizations" ... something that even the .NET CLR doesn't have yet

I think the CLR does have a JIT compiler. I also recall that sun's hotspot compiler was created as a reaction to JIT compilation in the Microsoft Java product (the precursor to CLR). That was back when they were going back and forth over Java. I could be remembering wrong.

2) PHP, being so crapy, is recompiled at every request, so that Zend can make a living

I really hope APC will be standard in PHP 6. There is no reason for it not to be. PHP standard should have at least an opcode cache. Leave the opcode optimization to commercial Zend. Perhaps having a standard opcode cache would force Zend to include JIT capability in their commercial product to take it to the next level?

3) The cost of a new process is higher than the cost of a new thread

Normally, one would tune an apache configuration to have a certain number of processes on hand to avoid creating new ones all the time.

[DerelictMan]

Well the site clearly states why php should have namespaces...but they don't offer a solution they offer ideas on how a solution would look like.

No, there is a nearly complete working patch available at that site. I was lurking on the Propel users list when the people that created that site were talking about it. The problem is the PHP devs were not terribly interested in looking at it. They have stated (finally) that they are planning on adding namespace support to the language in PHP 6 but they have decided not to use that patch and are starting over from scratch (which means, don't hold your breath).

I mean they clearly state what they are doing is for demonstration.

This disclaimer was added after Zend (or should I say, "The PHP Group") took issue with their use of the name "phpnamespaces.org". Zend felt that they were violating the PHP license by offering an effective "fork" of PHP with namespace support compiled in. That's when those in control of phpnamespaces.org added the disclaimer. The patch there is, by all accounts, quite stable and reliable (I have not used it myself... I don't like having to manually track changes and patches and prefer to stick with the official PHP distribution for maintenance reasons). Unfortunately it has not been accepted into the core and most likely will never be.

[sysice]

Oh JOY, arguements about what languages is the best never really get anywhere.

Paul Graham talks a lot about language, and of course he will side towards Lisp, but here is an interesting piece about Java.

http://www.paulgraham.com/javacover.html

This whole thing reminds me of the Mythbusters episode where they put the toy car against the real car. Over 100 feet the toy car was faster, but over 400 feet it was slower. It really comes down to the specifics of what you are measuring to determine if one is faster then the other.

[lo0ol]

Paul Graham talks a lot about language, and of course he will side towards Lisp, but here is an interesting piece about Java.

http://www.paulgraham.com/javacover.html

I agree with you on the boring language debates (and on the Mythbusters allusion- that was an interesting episode), but that link doesn't really add anything to the discussion:

So far, Java seems like a stinker to me. I've never written a Java program, never more than glanced over reference books about it

That's like saying "I've never been to Russia, I don't know anything about the culture or history of Russia, but I think it's a crappy country". In terms of making an argument, I personally think that falls short. Not to mention that he wrote it in 2001, and Java has come a long way since then.

[dc dalton]

Oh HOW have I missed this one for so long.

OK, Most people who know me are thinking "Here comes the fire and brimstone Java zealot" ....... sorry that was then.

Anyway, here some specific answers to somethings that made me twitchy:

There are also scalability issues to consider. It's a hell of a lot easier to build scalable PHP apps than it is scalable java apps.

I'm sorry but that has go to be one of the most uniformed things I have ever seen posted anywhere! Where oh WHERE do you come up with that and what proof do you have.

Why is it some of the largest enterprise web applications are written in Java? Power and Scalabilty! Look at Ebay, UPS, Fedex, PetsMart (I could go on for ever) .... I have yet to see an honest to god enterprise level application written in PHP ...... PLEASE show me one!

In my experience, Java runs faster but uses more memory. However it provides stateful execution through servlets. Use the right tool for the right job.

I know this has been answered but I had to add my 2 cents. High memory usage in Java apps almost always point to lousy coding! There are some things I've worked with (like the Java image API) that do tend to use some serious memory but nothing more than wouldn't be expected loading massive images into memory for manipulation.

I monitor my servers constantly (all Java enabled) and see NO extra memory use when the "big" apps are running .... again, high memory use in java = bad programming!

Java's startup cost means that you'll usually leave the process around and serve requests through that single process (the typical "application server" model). PHP's startup cost is extremely low, and the standard setup is to simply toss more instances of apache at the problem. As traffic increases, add more servers. It's pretty much infinitely scalable.

OK, now you really need to explain these "high start up costs"!!! WHAT STARTUP COSTS! The j2sdk is FREE, things like Apache's Tomcat (although not my fav) FREE .. 99% of the 3rd party APIs ... FREE, so what freakin costs are you talking about! And don't even give me that J2EE package from Sun.... NO self respecting Java developer would pay for that when you get the exact same thing in a servlet engine like Resin!

Just total horse hockey!

I do not program so I am not qualified to write this. I'll write my view on the matter from a non technical web surfers perspective.

Half the time php pages loud fast enough that I wouldn't know its in php. I ALWAYS know if its JAVA because the damn thing takes a little while to loud the java applet. After the applet is louded it works fine and is fast though. But I hate waiting for the damn thing to load in the first place. I want the information now, not in 10 seconds. Java also seems to use more of my system resources that a php application does... I don't always like that. Sometimes I might have 15 windows open including a few programs, lots of web sites, a music program, and some of those damn pdf files. Then you get another page that is java based... just what I needed, more resource drain.

But what do I know? I'm just the non-technical end user.

You are talking about something that is less than 1% of the use of Java ... Applets??? Oh for crying out loud .... talk about 1990s!

I could give you a list of sites and apps I've written in Java that you would NEVER be able to tell the were java powered and they are ALL SMOKING FAST!


Anyways ........ I'm NOT a "java for everything nut", I also use PHP for simple websites and apps, also for those clients who dont have Java enabled servers. PHP is fine for this type stuff, it's easy to write (usually) and works fast enough. BUT when I need a massive app that has to be able to do anything I need in any way shape or form I go to Java.

As far as faster? Without some really stupid tests I don't think anyone can prove it either way and honestly WHO CARES!

I've seen painfully slow apps in Java, PHP, ASP, Perl and .NET and you know what I find 99% of the time is the problem? LOUSY PROGRAMMERS who dont learn all the ins and outs of their language ... they buy a book, hack together some code and call themselves a programmer!

Most of these painfully slow apps all have one thing in common (besides lousy programming that is) .... they are running over a database and the programmer has NO CLUE how to effectively use that db! I've seen queries that would choke the most powerful servers in the world. I've seen loops that made call after call to dbs when in fact if the programmer knew what they were doing they could grab all the data in a view with one call AND let the database servers do what THEY do best, manage and serve DATA.

I'm actually looking at one of these hack apps right now as a matter of fact, freaking Tomcat 5, Hibernate, Struts and a Firebird database.... my god this thing makes me want to cry it's so slow ... another hacked together app by ANOTHER hack "programmer" who thought it was all so cool. I've told this company there is no way in hell I'll even try to fix this piece of crap ... it's a total rewrite!

So before any of you start with this "my language is faster than yours" just because you see a slow web app take a look at what ELSE could be wrong.... 9 times out of 10 it probably has NOTHING to do with the programming language at all!

[ShytKicka]

Whoever argues in this topic about either language, is not a successful developer, I'll tell you that.