Slashdot Mirror
Java IO Faster Than NIO
rsk writes "Paul Tyma, the man behind Mailinator, has put together an excellent performance analysis comparing old-school synchronous programming (java.io.*) to Java's asynchronous programming (java.nio.*) — showing a consistent 25% performance deficiency with the asynchronous code. As it turns out, old-style blocking I/O with modern threading libraries like Linux NPTL and multi-core machines gives you idle-thread and non-contending thread management for an extremely low cost; less than it takes to switch-and-restore connection state constantly with a selector approach."
JDK7 will bring a new IO API that underneath uses epoll (Linux) or completion port (Windows). High performance servers will be possible in Java too.
Look at the timestamp of this presentation :) It's a bit of old news.
It was discussed here: http://www.theserverside.com/news/thread.tss?thread_id=48449
And it mostly shows that NIO is deficient. I encountered similar problems in my tests. Solved them by using http://mina.apache.org/ .
Except NIO is usually not as straight forward as java io. It isn't particular hard to use either if you learn to use threads to handle the I/O and pass information through queues.
Reserved Word.
.COM languages? You mean a web language? You do realize Perl was written as a replacement for sed, awk and the shell languages (csh, bash, etc.), to make systems administration easier by providing a single language that used a familiar, C-like syntax and made text parsing trivial. The web was a non-entity when Perl was created. The fact that it was an acceptable language for web development is tied to the initial design goal of parsing text quickly, but that was never the purpose of Perl, and the spread of the language was not solely (and not even primarily) due to its use on the web.
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
but usually default to megabytes per thread, so if you have thousands of concurrent clients, you will soak up memory in fairly large quantities.
There's an important distinction to make here: a thread's stack will reserve (so many) kilobytes/megabytes of address space, but it won't actually use up very much RAM unless/until the thread starts to actually use a lot of stack space (e.g. by doing a lot of recursion).
On a 32-bit machine, starting too many threads can allocate all of your process's 2-4 gigabytes of address space, which can cause problems even though you have plenty of RAM still free.
On a 64-bit machine, on the other hand, the amount of available address space is mind-bogglingly huge, so running out of address space isn't a problem you're likely to run into, even if you run a gazillion threads at once.
I don't care if it's 90,000 hectares. That lake was not my doing.
I don't see how implicit variables are necessarily bad practice. It's a language convention. Programmers write for loops that iterate over variables named 'i' all the time, and it's usually accepted, if not condoned, even if it's just as lacking in descriptiveness as $_ (and $_ has a well defined role, where i is purely by convention). Perl uses $_ as the default loop variable, certain methods process it by default when provided no arguments, etc. If you know Perl well, it's quite natural. Similarly, @_ holds arguments passed to a function (having it be the default storage for return values is deprecated, so you don't see it all that often in other contexts), and shifting off it is standard. Don't assume your lack of familiarity means it's automatically poor style.
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print