Самый быстрый способ разбора больших строк (многопоточность)

Question

Я собираюсь запустить проект, который будет принимать блоки текста, анализируя много данных в них на какой-то объект, который затем может быть сериализован, сохранен и статистически/данные, полученные из. Это должно быть как можно быстрее, так как у меня есть> 10 000 000 блоков текста, которые мне нужно начинать, и получат 100 000 тысяч в день.

Я запускаю это на системе с 12 ядрами xeon + hyper threading. У меня также есть доступ/немного знать о программировании CUDA, но для струнных вещей думаю, что это не подходит. Из каждой строки мне нужно разбирать много данных, а некоторые из них я знаю, какие позиции я, а некоторые нет, и нужно использовать regex/something smart.

Так считают что-то вроде этого:

object[] parseAll (string [] stringsToParse) 
{ 
    parallel foreach 
      parse(string[n]) 
} 

object parse(string s) 
{ 
    try to use exact positions/substring etc here instead of regex's 
} 

Так мои вопросы:

• Сколько медленнее использует регулярное выражение, чтобы подстрока.
• Является ли .NET значительно медленнее, чем другие языки.
• Какую оптимизацию (если таковая имеется) можно сделать для максимизации параллелизма.
• Что-нибудь еще, что я не рассматривал?

Спасибо за любую помощь! Извините, если это долгое время.

Answer 1

Насколько медленнее используется регулярное выражение для substr.
Если вы ищете точную строку, substr будет быстрее. Однако регулярные выражения сильно оптимизированы. Они (или, по крайней мере, части) скомпилированы в IL, и вы можете даже сохранить эти скомпилированные версии в отдельной сборке, используя Regex.CompileToAssembly. См. http://msdn.microsoft.com/en-us/library/9ek5zak6.aspx для получения дополнительной информации.

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

Какую оптимизацию (если таковая имеется) можно сделать для максимизации параллелизма.
С помощью Task.Factory.StartNew вы можете планировать задачи для запуска в пуле потоков. Вы также можете взглянуть на TPL (Task Parallel Library, из которых Task - часть). У этого есть много конструкций, которые помогут вам распараллеливать работу и позволяют строить такие конструкции, как Parallel.ForEach(), для выполнения итерации по нескольким потокам. См. http://msdn.microsoft.com/en-us/library/dd460717.aspx для получения дополнительной информации.

Что-нибудь еще, что я не рассматривал?
Одна из вещей, которая повредит вам этим объемом данных, - управление памятью. Несколько вещей, чтобы принять во внимание: выделение памяти

• Limit: попытаться повторно использовать одни и те же буфера для одного документа, вместо того, чтобы копировать их, когда вам нужна только часть. Скажем, вам нужно работать с диапазоном, начинающимся с char 1000 до 2000, не копировать этот диапазон в новый буфер, а строить свой код для работы только в этом диапазоне.Это сделает ваш код сложным, но он сохранит вам выделение памяти;

• StringBuilder - важный класс. Если вы еще не знаете об этом, посмотрите.

Answer 2

Google недавно объявил, что это внутренний язык обработки текста (который, как представляется, как подмножество Python/Perl сделал для параллельной обработки в значительной степени).

http://code.google.com/p/szl/ - Sawzall.

Answer 3

Я не знаю, какую обработку вы здесь делаете, но если вы говорите сотни тысяч строк в день, это кажется довольно маленьким числом. Предположим, что вы получаете 1 миллион новых строк для обработки каждый день, и вы можете полностью выполнить 10 из этих 12 ядер Xeon. Это 100 000 строк на ядро ​​в день. Есть 86 400 секунд в день, поэтому мы говорим 0,864 секунды за строку. Это лот разбора.

Я повторю рекомендации, сделанные @Pieter, особенно там, где он предлагает сделать измерения, чтобы узнать, сколько времени потребуется для обработки. Лучше всего получить что-то вверх и работать, затем выяснить, как сделать это быстрее, если вам нужно. Я думаю, вы будете удивлены тому, как часто вам не нужно оптимизировать. (Я знаю, что это ересь для мастеров оптимизации, но время процессора дешево и время программиста дорого.)

Насколько медленнее используется регулярное выражение для substr?

Это зависит полностью от того, насколько сложны ваши регулярные выражения. Как сказал @Pieter, если вы ищете одну строку, String.Contains, вероятно, будет быстрее. Вы также можете использовать String.IndexOfAny, если вы ищете постоянные строки. Регулярные выражения не нужны, если вы не ищете шаблоны, которые не могут быть представлены как постоянные строки.

Является ли .NET значительно медленнее, чем другие языки?

В приложениях с интенсивным процессором .NET может быть медленнее, чем собственные приложения. Иногда. Если это так, он обычно находится в диапазоне от 5 до 20 процентов и чаще всего от 7 до 12 процентов. Это всего лишь код, выполняющийся изолированно. Вы должны учитывать другие факторы, например, как долго вы занимаетесь разработкой программы на этом другом языке и насколько сложно делиться данными между родным приложением и остальной частью вашей системы.

Answer 4

Если вы хотите выполнить быстрый синтаксический анализ строк на C#, вы можете рассмотреть возможность взглянуть на новый проект NLib. Он содержит строковые расширения для быстрого поиска строк. Например, IndexOfAny (строка []) и IndexOfNotAny. Они также содержат перегрузки с аргументом StringComparison.