SitePoint Sponsor

User Tag List

Page 7 of 8 FirstFirst ... 345678 LastLast
Results 151 to 175 of 190
  1. #151
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Viflux
    In the grand scheme of a web request, the time spent at the server is but a fraction of the whole.

    It's like arguing about whether the Porsche or the Mercedes is faster, even though both are limited by the speed limit on the highway.
    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

  2. #152
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In the grand scheme of a web request, the time spent at the server is but a fraction of the whole.
    This is a bit silly....it totally depends what you are doing and what the connection speeds are.
    Schlossnagle agrees with you.
    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.

  3. #153
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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).

  4. #154
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  5. #155
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Snaily
    The regex engine in PHP is done in C...so this would explain why its able to match Java in speed (and even do a bit better).
    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.

  6. #156
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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).

  7. #157
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    Denmark
    Posts
    1,222
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    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

  8. #158
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Snaily
    You can compare the languages....just don't use any native extensions beyond the primative ones (i.e. arrays).
    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.

  9. #159
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  10. #160
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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)

  11. #161
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why shouldn't you compare native extensions?
    They are, after all, native.
    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.
    How is this a fair comparison of the two languages?

  12. #162
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    Denmark
    Posts
    1,222
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Snaily
    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.
    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

  13. #163
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Benjymouse
    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.
    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.

  14. #164
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Snaily
    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.
    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

  15. #165
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Comparing the raw language makes no sense.
    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.
    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.
    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.

    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.

  16. #166
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Viflux
    In the grand scheme of a web request, the time spent at the server is but a fraction of the whole.

    It's like arguing about whether the Porsche or the Mercedes is faster, even though both are limited by the speed limit on the highway.
    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.

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

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

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

    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.
    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().

    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.

  17. #167
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    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.

  18. #168
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  19. #169
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Snaily
    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.
    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?

  20. #170
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    because PHP is a Web development framework and Java is a general purpose engine
    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.
    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".
    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.
    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).
    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?
    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.

  21. #171
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't know what industry you're in, but my customers rarely complain that some of my PHP extensions are written in C.

  22. #172
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  23. #173
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why does my development process suffer because I'm using the regex extensions?

  24. #174
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > 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.

  25. #175
    SitePoint Addict Trent Reimer's Avatar
    Join Date
    Sep 2005
    Location
    Canada
    Posts
    228
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    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";
    ...or if you prefer Java...

    WriteFile.java
    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");
      }
    }
    Now to read the thing...

    read_file_to_string.pl
    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";
    ...and the same in Java...

    ReadFileToString.java
    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");
      }
    }
    Notes:

    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?


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •