2010-06-29 4 views
1

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

+0

Язык будет мало или совсем не отличается. –

+1

... это называется ненужным/преждевременным оптимизацией. –

+0

Учтите, что все языки, которые вы указали, просто вызывают ОС для выполнения ввода-вывода файлов. –

ответ

3

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

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

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

3

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

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

0

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

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

+0

Я согласен, что перекрывающиеся ввода-вывода хороши (во-вторых, сопоставление файлов), но для получения перекрытого 'FileStream' вы * имеете * для использования одного из конструкторов, который берет логический параметр' async' и передает 'true'. 'File.Open', et. и др. не используйте перекрывающиеся входы/выходы. –

+0

Я попрошу некоторых людей, которых я знаю, но я подозреваю, что файл с отображением mem использует перекрывающиеся ввода-вывода под капотом. –

+0

Нет; файлы с отображением памяти - это совсем другой подход. [Windows Internals] (http://tinyurl.com/23seaj8) имеет отличное описание того, как работают различные методы ввода-вывода. –

Смежные вопросы