Разбор двоичных файлов: производительность - PullRequest
1 голос
/ 29 июня 2010

У меня есть большой двоичный файл для анализа, и я не уверен, какой язык использовать для повышения производительности.Первоначально я собирался использовать C # WPF в качестве графического интерфейса и AC DLL для анализа.но мой целевой компьютер - 64-битная машина.и у меня были проблемы с настройкой проекта AC DLL в VS 2008. Поэтому я думаю, что мне следует перейти на c ++ или c #, чтобы выполнить анализ.Я просто не уверен в скорости чтения файлов c ++ / C #, так как мой файл довольно большой.скорость очень важна.Кто-нибудь может дать мне несколько советов?спасибо.

Ответы [ 3 ]

3 голосов
/ 29 июня 2010

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

Как правило, я рекомендую использовать сопоставление файлов (доступно в .NET 4.0 в новом MemoryMappedFile класс).Это хорошо, если вы не выполняете однопроходное сканирование в прямом направлении, которое может быть выполнено с использованием обычного потока.

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

3 голосов
/ 29 июня 2010

Выберите любой язык, на котором пишете остальную часть программы. Запустите поток файлов и прочитайте присоску.

Независимо от того, какой код вы используете, он все равно будет ждать на диске, чтобы найти, где находятся данные.

0 голосов
/ 29 июня 2010

Поскольку у вас Windows, жизнь немного проще, чем на некоторых других платформах, из-за превосходного Перекрывающегося IO API Это то, что вы хотите использовать, если вы действительно пытаетесь выжать производительность. Перекрытый IO позволяет IO происходить не по порядку. Вы заметите, что FileStream фактически использует перекрывающийся ввод-вывод под капотом. Если вы можете работать в рамках его ограничений, просто используйте это. В противном случае создайте управляемую оболочку c ++, чтобы выполнить чтение за вас с помощью ReadFile.

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

...