Java NIO против производительности DotNet IO

Question

Кто-нибудь знает, в чем разница между производительностью Java NIO и производительностью DotNet IO.

Чтение Этот вопрос, кажется, что стандартные Java-IO и DotNet-IO имеют очень похожие IOпроизводительность.

Что меня интересует, так это то, что ребята из Java утверждают, что массовое копирование файлов, операции на файловом сервере и т. д. должны выполняться намного быстрее из-за доступа к файловым каналам и т. д. в Java-NIO.

Возможно ли, что производительность java.nio лучше, чем у DotNet System.IO.

Спасибо.

Answer 1

Я на самом деле не могу ответить на это, но я могу свободно мыслить ...

.. и Java-File-IO, и .Net должны использовать нижележащие операции ОС для доступа к файлу, а доступ к файлу всегда связан с вводом-выводом, а не с процессором. Это означает, что диски работают медленнее, чем процессор и память.

Что это будет означать, так это то, что Java-File-IO и .Net должны быть одинаковыми с точки зрения производительности.

Когда дело касается связи через сокет, Java проделала ужасную работу и фактически просто проигнорировала стандарт Posix и не использовала вызов ОС «select». Это было исправлено в Java NIO с введением «каналов», которые являются не чем иным, как поддержкой поддерживающей архитектуры. Прежде чем вам нужно было выделить поток для каждого сокета, на котором вы читали, ужасная трата ресурсов.

Поскольку .Net новее Java, я бы поверил, что они никогда не попадали в эту ловушку и с самого начала добавили поддержку для этого. Но я не использовал .Net, поэтому могу сказать, что не могу догадаться. 1009 *

Относительно связи через сокеты в обоих случаях Java-NIO и .Net System.IO оба должны быть связаны с сетью, прежде чем они все равно будут связаны с ЦП. Поэтому я не думаю, что один будет быстрее другого.

Answer 2

Что касается копирования файлов, не должно быть существенных различий, независимо от того, какую платформу или API вы используете.горлышко бутылки - это вращение диска и поиск жесткого диска.*

Что должно произойти, это переместить содержимое жесткого диска в некоторую память, а затем записать память на жесткий диск.с традиционным потоком java io, будут дополнительные копии памяти.тем не менее, это не значительная трата по сравнению со скоростью диска.

это легко проверить, FileChannel.transferTo / From не может превзойти старый способ копирования потока ввода-вывода.

(*), конечно, сейчас есть намного более быстрые диски, нопока мы определяем диск как следующее более медленное хранилище после памяти, аргумент сохраняется.

(**) мы могли бы назвать виртуальный диск диском, который фактически находится в основной памяти.тогда копия памяти - это горлышко бутылки, и аргумент больше не держится.