Schlossnagle agrees with you. I think the link deserves to be repeated:Originally Posted by Viflux
http://www.schlossnagle.org/%7Egeorg...ky-Answer.html
| SitePoint Sponsor |
Schlossnagle agrees with you. I think the link deserves to be repeated:
http://www.schlossnagle.org/%7Egeorg...ky-Answer.html
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
This is a bit silly....it totally depends what you are doing and what the connection speeds are.In the grand scheme of a web request, the time spent at the server is but a fraction of the whole.
His point is that the fact that PHP is slower does not effect its ability to scale...this is true. He does not claim that the fact that Java is faster simply doesn't matter...which is false.Schlossnagle agrees with you.
The point isn't about connection speeds or what you're doing.
The point is that the difference of speed between various platforms is negligible next to the length of time spent transporting the request and subsequent response, something we, the developers, have absolutely no control over (in typical, public facing web applications).
And I repeat this is silly....this is not unverisally true...it depends what you are doing with your web application. In some cases its negligible...in other cases it makes a big difference.The point is that the difference of speed between various platforms is negligible next to the length of time spent transporting the request and subsequent response, something we, the developers, have absolutely no control over (in typical, public facing web applications).
For Pete's sake, Snaily... Everything in PHP is implemented in C, except for user code. This is why you can't compare Java and PHP straight 1-to-1.
This was the point of the comment..... Benchmarking PHP's regex engine to Java's is not benchmarking the languages. Java's regex engine is writen in pure java...PHP outsources the job to C. If you were to implement a regex engine in PHP it would be extremely slow. You can compare the languages....just don't use any native extensions beyond the primative ones (i.e. arrays).For Pete's sake, Snaily... Everything in PHP is implemented in C, except for user code. This is why you can't compare Java and PHP straight 1-to-1.
The Java VM is also implemented in C (or C++). Taken as a stack PHP+interpreter+library vs. Java+JIT+library of course you can compare them.
I'll readily agree that you should be very careful about concluding anything about web applications on the basis of synthetic benchmarks. However it stands that both theory and benchmarks suggest that Java (the programming language) executes a lot (!) faster then PHP (as a programming language).
When the programming problem hits an area in which PHP has implemented a specialized algorithm in C (and Java has it implemented in Java), PHP may show a little advantage.
While the server side processing may be only a fraction of the latency that users experience on simple page requests, this does not allow us to become processor pigs. With a shared hosting provider (sufficient bandwidth), server side (in)efficiency may indeed become the bottleneck when many users hit your site.
/mouse
You gotta excuse me here but since when did you write the rules on how we are allowed to compare languages? I'm on nobodys side, but that statement is just stupid.
err...huh? If you want the comparison to be fair and tell you something about the languages in themselves then one should not include native extensions. Please tell me what is stupid about this.You gotta excuse me here but since when did you write the rules on how we are allowed to compare languages? I'm on nobodys side, but that statement is just stupid.
Why shouldn't you compare native extensions?
They are, after all, native.
It's like comparing a Dell to an HP and saying it's not fair because Dell has a Pentium 4. (well not exactly, but you get the point...I should hope)
Ugh.... Because it says nothing about the language as they are writen in another language? Furthermore the example of the regex engine...in one case its a native extension in the other its not.Why shouldn't you compare native extensions?
They are, after all, native.
How is this a fair comparison of the two languages?
Comparing the raw language makes no sense. It's a lot more interesting to compare how the typical setup for each language fares in a specific problem domain (like web development). Regex'es are often used in this problem space. The regex implementation is generally available to developers, also on shared PHP hosting. IMHO this makes it a fair comparison.
/mouse
I agree.
If we remove all the C extensions used by PHP, there's not a whole lot left. Certainly not a viable subset for web development.
Therefore, to compare PHP to Java in a web development context you have 2 options.
You can forego the use of C extensions, and thus Java is a clear winner as PHP's functionality drops exponentially, to the point where it is rendered nearly unusable.
Or, more intuitively, you can compare the two as they come, out of the box.
I don't get this. Can you give us some kind of example or scenario to show when it matters performance-wise but doesn't affect scalability?
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
Why is that? What if you want to know the speeds of the "raw languages"? After all if you have to implement an algorithm isn't this what you care about? If the algorithm I need doesn't already have an extension in PHP what do I do? OH yeah...I have to use the "raw language" to implement it. And when you do this....the speed for your application is going to drop greatly. In Java there is no reason to write native functions to implement an algorithm efficiently, becuase the language is fast enough in itself.Comparing the raw language makes no sense.
This is actually not true. For any main stream extension you can find a pure PHP package that does the same thing...they just aren't used...because they are extremely slow.If we remove all the C extensions used by PHP, there's not a whole lot left. Certainly not a viable subset for web development.
Anyhow PHP is a great "glue language" for C/C++, but its performance as a language is really bad compared to languages like Java, .NET etc.
Not really. If your application serves a page in 10 seconds, users will notice.
Will users care if it takes 0.1 seconds or 0.2 seconds? Probably not. But if your application doesn't scale well, what was "fast" (less than 1 second) yesterday may be slow tomorrow.
Response time becomes even more important with web applications.
Here's the rub:
Web servers are mostly memory bound, and, as a result, can only handle so many open connections at once. CPU resources are rarely ever an issue (unless you start thrashing, of course!) It's all about the memory. If you can make an app take up 30% less memory, you'll be able to serve a lot more connections at once.
On the other hand, if requests take 1.5 second to complete instead of 1 second, things start to get messy as your load increases, because you have to choose between refusing requests and spawning more and more threads until the load dies down.
The average web site will probably never have to worry about more than 100 requests per second or so most of the time. For people who are only working on projects of that scale, the performance characteristics of the language you use probably don't matter one way or the other, since pretty much every request you perform will take just a few milliseconds either way.
What nonsense. Every time you do anything in any language you're ultimately making calls to the kernel, which is implemented in C. Java programs frequently use C libraries for all sorts of tasks. Just because something is abstracted away from you through a virtual machine doesn't mean that it isn't happening. Even the JREs are written in C.This was the point of the comment..... Benchmarking PHP's regex engine to Java's is not benchmarking the languages. Java's regex engine is writen in pure java...PHP outsources the job to C. If you were to implement a regex engine in PHP it would be extremely slow. You can compare the languages....just don't use any native extensions beyond the primative ones (i.e. arrays).
Hell, if you want to get really technical, neither language can do ANYTHING without some other language. Java programs can't run natively (i.e. with no external dependencies beyond the application file) on any hardware that I'm aware of, nor can PHP. It's certainly possible to create hardware that they can execute on, but nobody's going to bother. As long as Java apps are dependent on the JRE, they're not "pure java".
Yeah, in theory. In practice you'll almost never actually be writing some highly complex algorithm that has to be implemented in native PHP in the first place. Nonsense.Why is that? What if you want to know the speeds of the "raw languages"? After all if you have to implement an algorithm isn't this what you care about? If the algorithm I need doesn't already have an extension in PHP what do I do? OH yeah...I have to use the "raw language" to implement it. And when you do this....the speed for your application is going to drop greatly. In Java there is no reason to write native functions to implement an algorithm efficiently, becuase the language is fast enough in itself.
Every single function call in PHP is an "extension" (many just happen to be included in the "core"). This means everything from fopen() to print().This is actually not true. For any main stream extension you can find a pure PHP package that does the same thing...they just aren't used...because they are extremely slow.
And you've gone way beyond the whole argument being given in this thread. Nobody is going to claim that PHP is faster than Java in terms of number crunching and such. It's not. We know that. It'll never be faster -- nor should you expect it to be. The only valid way to test application performance is to test the performance of the entire system.
To illlustrate this, lets try this example:
Lets say that every single opcode in Java executes faster than every opcode in PHP except for a small subset, which PHP performs faster. 99% of all the possible operations you can do in java is faster than their PHP equivilents. That should guarantee that every Java app is faster, right?
Well, what if that small subset are the control statements?
Very, very little logic in web apps boils down to processor intensive things like number crunching. Most web apps are doing WAY more string processing, and php handles strings faster than Java in many (if not most) cases.
Seriously....this is just stupid. Java has a runtime system...so does PHP...the point is ahem...which runtime system is faster? Yes the runtime systems are writen in C/C++...and? PHP's regex engine is not part of the runtime system...its an extension. Maybe the part where they call it an "extension" gives it away? PHP extensions give one the ability to access C code via PHP, you can do the same in java (its just not done as often). Therefore if you want to know which runtime system is faster you will not compare algorithms that are outsourced to extensions (e.g regular expressions). You could after all implement a regex engine in C and access it via java if you really wanted to....of course there is no point as Java's runtime system is fast enough to handle it where as PHPs is not.Java programs frequently use C libraries for all sorts of tasks. Just because something is abstracted away from you through a virtual machine doesn't mean that it isn't happening.
I skipped most of later posts, because all seem to miss one important point: you can't compare PHP to Java, because PHP is a Web development framework and Java is a general purpose engine. Everything else (e.g. what is an extension and what is part of native code) is completely beside the point.
No, that was never the point. 99% of PHP developers will never need to write a PHP extension. As far as they're concerned, it's all "part of the language". If writing applications is easier and they perform faster, who gives a damn whether they're implemented as "extensions" or if they're part of the run time?
Oh, by the way -- I can recompile the PHP runtime to embed any extension that I want. Are they still "extensions" now, or are they part of the "runtime"? Why on earth does this distinction matter?
PHP is not a "web development framework", its a language that was built with the web in mind. Just as perl is not "string processing framework". But comparing PHP and java for web use becomes very hard... so the only thing you can do meaningfully is compare the raw languages etc.because PHP is a Web development framework and Java is a general purpose engine
Yes it is the point...if what you want to do is compare the languages in themselves and there are many reasons why this would be desired. It is true that your average script kiddie doesn't and shouldn't care though...but that isn't the point.No, that was never the point. 99% of PHP developers will never need to write a PHP extension. As far as they're concerned, it's all "part of the language".
Also the big sites using PHP have custom extensions...in fact this is one reason some use it...you can use it as a glue language over existing C/C++ code (e.g. yahoo).
You don't need to recompile PHP to add extensions.....and the distinction matters because extensions are no longer writen in PHP and they are very hard to manage in large projects.Oh, by the way -- I can recompile the PHP runtime to embed any extension that I want. Are they still "extensions" now, or are they part of the "runtime"? Why on earth does this distinction matter?
I don't know what industry you're in, but my customers rarely complain that some of my PHP extensions are written in C.
Why would the customers complain? Its the development process that suffers when you use custom extensions.I don't know what industry you're in, but my customers rarely complain that some of my PHP extensions are written in C.
Why does my development process suffer because I'm using the regex extensions?
> Java programs frequently use C libraries for all sorts of tasks.
> In practice you'll almost never actually be writing some highly complex algorithm that has to be
> implemented in native PHP in the first place. Nonsense.
For very critical systems these systems won't be developed with Java either, never mind developed with PHP; You would use a lower level langauge or technology, and that is a fact of the matter.
If I can foolishly interject on the large string speed issue again, I am still having some difficulty matching my cumbersome string test to Snaily's assertions. I'll post my code below...
First create a large text file...
write_file.pl
...or if you prefer Java...Code:#!/usr/bin/perl $total = 1000000; open(FH, '>', '/tmp/file.txt'); for ($i = 1; $i <= $total; $i++) { print FH $i; } close(FH); $interval = times; print "Task complete in $interval seconds.\n";
WriteFile.java
Now to read the thing...Code:import java.io.*; import java.util.*; class WriteFile { public static void main(String[] args) throws IOException { Date interval = new Date(); long start = interval.getTime(); int total = 1000000; FileWriter outfile = new FileWriter("/tmp/file.txt"); for (int i = 1; i <= total; i++) { outfile.write(Integer.toString(i)); } outfile.close(); interval = new Date(); long stop = interval.getTime(); float timeElapsed = stop - start; timeElapsed = timeElapsed / 1000; System.out.println("Task complete in " + Float.toString(timeElapsed) + " seconds"); } }
read_file_to_string.pl
...and the same in Java...Code:#!/usr/bin/perl $contents = ''; $file = '/tmp/file.txt'; open(FH, "$file"); while ($line = <FH>) { $contents .= $line; } close(FH); $interval = times; print "Task complete in $interval seconds.\n";
ReadFileToString.java
Notes:Code:import java.io.*; import java.util.*; class ReadFileToString { public static void main(String[] args) throws IOException { Date interval = new Date(); long start = interval.getTime(); FileReader infile = new FileReader("/tmp/file.txt"); BufferedReader reader = new BufferedReader(infile); String contents = new String(); String line = new String(); while ((line = reader.readLine()) != null) { contents += line; } infile.close(); interval = new Date(); long stop = interval.getTime(); float timeElapsed = stop - start; timeElapsed = timeElapsed / 1000; System.out.println("Task complete in " + Float.toString(timeElapsed) + " seconds"); } }
Java is measurably faster than Perl in creating the file.
I still found Perl to complete the read to string task about 10x faster than Java.
Question: Is there a more efficient way to transfer the file contents to a String or StringBuffer in Java? I did a line read since that was the most efficient mechanism I googled. In order to compare apples to apples you will notice that I set the Perl script similarly to read by line.
I capped the file creator at a million iterations so that reading the file would comply with my default JRE memory settings without throwing java.lang.OutOfMemoryError. While it limits the test (to more reasonable proportions) it also shows Java has improved in terms of throwing errors long before crashing the system. That's awesome for careless programming and I would point out that I could not say the same for Perl.
Comments?
Posting Permissions
Bookmarks