$file = <FILE>;
[download]

This is going to be handled by an opcode or two, that will run at C speed. On the other hand, the Java implementation is forced to use an explicit loop to fetch all the contents of the file. Other things being equal, this will kill Java.

What does really strike me, though, is the fact that the Java version is about three times as long. In terms of programmer efficiency, that's an important factor to take into consideration. Much more so that raw I/O throughput.

I'm no expert at understanding Perl's op codes, but if you do a perl -MO=Terse copyfile you can get a feeling for what is going on under the hood.

Dwelling on this overnight, it occurred to me that the java implementation is not following the spec "read a file in to a variable". The Perl implementation is slurping the entire file into a variable, which puts considerable effort on the VM manager. The Java implementation, on the other hand, is reading a bit from the input file, and then writing a bit to the output file, until the input file is exhausted.

At no time does the Java version hold an entire copy of the file in core, whereas Perl does, paying the added cost of system overhead while the kernel frantically discards 10 megabytes of pages used for caching and buffering, in order to give them to the Perl process.</>

A fairer comparison would be to use this code:

  open(IN, $ARGV[0]);
  open(OUT, ">$ARGV[1]");
  print OUT <IN>;
  close IN;
  close OUT;
[download]

Looking at it that way, it's clear the Perl programmer would have already typed in the program, corrected spurious syntax errors, run the program, received the results, before the Java programmer had finished typing in the Java program.

A couple things. I don't see the looping that you're talking about in the java versions. The java version from the original poster provides 2 methods for copying, and both read the whole contents of the file into an array and then write that array out to a new file. So the overall idea *is* the same: read the entire first file into memory, write that memory to a second file.

Also, you do realize that the java "version" is actually 2 different methods? So it's not really as long as it appears. Additionally, condensing the JDK 1.4 version I gave below down to some hideuos anonymous objects it gets pretty short. Not on par with the perl version, but hey, that's one of perl's features.

import java.io.*;
import java.nio.*;
import java.nio.channels.*;

public class X2 {
  public static void main (String [] args) throws Exception {
    FileChannel in = new FileInputStream(args[0]).getChannel();
    new FileOutputStream(args[1]).getChannel().write(in.map(
      FileChannel.MapMode.READ_ONLY, 0, in.size()));
  }
}
[download]

Cheers,

- danboo

use strict;
use warnings;
my $data;
open(FILE,"<yourfile") || die "oops $!";
{
  local $/ = undef;
  $data = <FILE>;
}
close(FILE);

open(FILE2,">file2");
print FILE2 $data;
close(FILE2);
[download]

You might also be interested in this recent article discussing natively compiled Java.

Cheers,

- danboo

Ok, i whipped up a version using JDK 1.4 and the java.nio package. It's faster than either of the other versions on my system.

[danboo@danboo 04:37pm ~/java]$ java X ten_meg_file__2.txt out__2
Time = 492
Buf Time = 432
[danboo@danboo 04:37pm ~/java]$ perl X.pl ten_meg_file__2.txt out__2
0.192673087120056 Seconds Elapsed.
[danboo@danboo 04:37pm ~/java]$ java X2 ten_meg_file__2.txt out__2
Time = 128
[download]

Source for X2.java:

import java.io.*;
import java.nio.*;
import java.nio.channels.*;
 
public class X2 {
 
  public static void main (String [] args) {
 
    try {
 
      long l = System.currentTimeMillis();
      FileInputStream input   = new FileInputStream(args[0]);
      FileOutputStream output = new FileOutputStream(args[1]);
 
      FileChannel inputChannel  = input.getChannel();
      FileChannel outputChannel = output.getChannel();
 
      int inputLength = (int) inputChannel.size();
      MappedByteBuffer buffer = inputChannel.map(FileChannel.MapMode.R
+EAD_ONLY, 0, inputLength);
      outputChannel.write(buffer);
      System.out.println("Time = "+ (System.currentTimeMillis()-l));
 
    }
   catch (Exception e) {
     e.printStackTrace();
   }
 
  }
 
}
[download]

Note: This is my first time using the new 'java.nio' package for memory mapped file operations. There may be better ways to do it. I don't necessarily believe these tests are accurate.

Cheers

- danboo

For those who are interested look at the java.nio.channel for a comparison. The reading on the FileChannel class is interesting as it covers this specific topic.

It does some quite nice things with optimising access to large files. However as I have only just downloaded it I couldn't say if its great or quicker than Perl even. Not that I really mind either way :)

Note that on some platforms Perl's I/O is faster than C's buffered I/O (about twice as fast) which probably means it will be faster than Java's I/O. On other platforms, Perl's buffered I/O is about 1/2 as fast as C's buffered I/O. Linux is one of the platforms were Perl's I/O is slow.

If "perl -V" reports "d_stdstdio=define", then Perl's I/O is probably fast on your platform.

So your friend picked one of the things that Perl can be very fast at because Perl does really scary hacks to make I/O fast but only on platforms where the Configure tests show that those scary hacks actually work.