3 ms·

I guess I'm not surprised. My reason for using NIO in the past has been because I've had systems that supported many long-running, mostly idle open sockets. See

• rkalla 16y ago
  I don't know the scale of "many" here, but in the thousands, I think Paul's presentation makes the case for threads given the near free cost of having idle threads sitting around and activating/deactivating them as long as they aren't contending for something. A few folks have mentioned that the cost of context switching and state-restore using NIO is more expensive than this especially on a multi-cored machine which I thought was interesting. Again, I don't know how helpful that is to you, because your "many" could have meant 10s of thousands of connections, in which case threads wouldn't be the answer. Unless you wanted to get fancy with a hybrid approach ;)
• bnoordhuis 16y ago
  You're spot on. NIO has always been slower but it allows you to process more concurrent connections. It's essentially a time/space trade-off: traditional IO is faster but has a heavier memory footprint, NIO is slower but uses less resources.
  • dylanz 16y ago
    ... and I think your synopsis is spot on as well. If someone could counter this, I'd love to hear it.