So why is Java so slow? Let’s take a closer look.
Java checks the bounds of every array on every access at runtime. Many runtime errors are smoothly handled by array bounds checking, but this necessarily adds time to the execution of your program, because doing something takes longer than not doing it. This is especially noticeable in tight loops. Bounds checking is a welcome relief to many programmers used to C/C++, where a single bad array reference can crash your program.
Until recently, there has been nothing
in Java like the Unix
select( ) or
poll( ) system calls, which can be used to tell when a socket has
data ready for reading by the program. In Java, simply try to
read. If there is data, fine, read it. If not,
sorry — that
read is stuck until there is
data to read. That is, all
reads in Java are
reads, which means that they must be in a
separate thread if the entire program is not to hang, waiting for
Even if you have multiple threads, blocking I/O is not efficient. First, the reading thread will be awakened and put back to sleep repeatedly. It would be more useful to have a function that could generate an event when a socket has data ready. Second, using one thread per client connection severely limits scalability, since the number of concurrent connections that can be handled by the server will be limited by the number of concurrent threads that can be sustained by the system. ...