Ускорение обработки строк+запись в файл

@SharpA · Регистрация: 16.05.2013

Студворк — интернет-сервис помощи студентам

Добрый всем день. Подскажие, пожалуйста, можно ли оптимизировать мой код для ускорения выполнения? Суть такова: я открываю большой текстовый файл (до гигабайта), считываю по 1 строке, далее провожу манипуляции со строкой ( делаю из строки вида http://site.ru/folder1/file1.html строку site.ru, тут уже на что хватило ума, заранее извиняюсь)) и сразу же записываю отредактированную строку в другой файл. Вот сам код:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
FileInfo f = new FileInfo(@"file.txt");
using (FileStream fs = f.Open(FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
            {
                using (StreamReader sr = new StreamReader(fs, Encoding.UTF8))
                {
                    using (StreamWriter file2 = new StreamWriter(@"file_out.txt",true))
                    {
                        while (!sr.EndOfStream)
                        {
                                buf = sr.ReadLine();
                                Regex_new = new Regex(@"https?\:\/\/(.*?)\.(.*?)\/");
                                matches = Regex_new.Matches(buf);
                                if(matches.Count>0) buf = matches[0].Groups[0].Value;
                                buf = buf.Replace("http://","");
                                buf = buf.Replace("https://", "");
                                buf = buf.TrimEnd('/');
                                file2.WriteLine(buf);
                        }
                        file2.Dispose();
                    }
                    sr.Dispose();
                }
                fs.Dispose();
            }

Заранее благодарю за помощь.

@Dexiny · 09.06.2013, 03:47

откуда разы возьмутся, если время работы Regex 15%, остальное время тратится на декодинг/энкодинг и индексирование строк. Вы просто ниразу не писали таких программ, поэтому понятия не имеете. А толкать умные слова по потокам и массивам любой школьник 3 класса может.

Добавлено через 4 минуты
Ща короче высплюсь и завтра набросаю профилирование данного кода и анализом его ускорения

я же не патентую ничего

Dr_Quake · 09.06.2013, 03:49

Если с VD на другой VD - две линейных операции - столько примерно бонуса и будет, это да. Но из-за малограмотного программиста что будет кто-то такое организовывать итд - да ну нафиг, а руководство этого и не поймёт то...

Добавлено через 23 секунды
О б-же, да ни при чём тут твой код(кроме, конечно, однопоточного regex)... Всё упирается в IO...

@Dexiny · 09.06.2013, 03:50

Сообщение от Dr_Quake

Всё упирается в IO...

Эврика! Ты наконец-то это понял

Всё теперь я нормально усну.

Dr_Quake · 09.06.2013, 03:51

Rest in peaces!

Комментарий модератора

Dr_Quake, официальным языком на форуме является - русский.

@Dexiny · 09.06.2013, 16:37

И так начнём анализ кода автора, как я и обещал. Анализ будет проводиться с помощью процессорного профайлера, запись в файл идти будет без Flush, то есть время скидывания данных в файл учитываться не будет, нам важно вычислить максимальную производительность регекса при разных условиях (скорость чтения файла). Программа работает на RAM-диске, то есть скорости получаются максимально возможные. И так начнём.
Сначала профилируем первоначальный код автора без изменений. Картинка test1.png

Code
1
Test1 time elapsed :: 132,294s Avr.ReadSpeed :: 7,74 Mb/s 100%

Регекс написан некорректно и его стоит вынести за пределы цикла.

Далее исправляем регекс, пишем дополнительные опции, главная из них RegexOptions.Compiled. И зачем нам реплейсы, когда мы можем сразу вытащить название сайта. Получаем в итоге такой регекс.

C#
1
var _regex = new Regex(@"https?://(?<site>[^/]+)/?", RegexOptions.ExplicitCapture | RegexOptions.CultureInvariant | RegexOptions.Compiled);

Профилируем исправленный код. Картинка test2.png

Code
1
Test2 time elapsed :: 10,008s Avr.ReadSpeed :: 102,3 Mb/s 1321,9%

Ситуация уже получше, видим примерно равное распределение между чтением, парсингом и записью. Прирост 13-кратный.

Далее проверяем моё предположение на счёт складывания строк в массив и парсингом регексом массива размером около 32кб. Картинка test3.png

Code
1
Test3 time elapsed :: 14,298s Avr.ReadSpeed :: 71,62 Mb/s 925,3%

Скорость увы получилась хуже, чем парсинг по одной строки. Но зато можно здесь потестить, что если вкладыват ьв регекс строку размером выше 32кб, скорость будет падать (попробуйте вместо 28000 написать 64000). И теперь мы можем применять разные потоки, если ресурсов процессора не жалко

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

Code
1
Test4 time elapsed :: 10,917s Avr.ReadSpeed :: 93,8 Mb/s 1211,8%

То есть почти догнали линейный алгоритм. Можно ещё применить не 1 поток регекса, а 2, получим где-то +15% к скорости. Распараллелить чтение строк из файла - считывать линейно массивы байт, затем раздавать их отдельным потокам Decoding. Но это увы слишком затратно с точки зрения процессорного времени и потребления. Лучше переписать линейный алгоритм парсинга на Си, запилить библиотеку dll и подключить к проекту сишарпа.

Я не стал переписывать алгоритм извлечения строк (просто некогда ща). Но скажу, что скорость становится в районе 150-180Мб/с при использовании 3 ядер коре i7-2600K. Сишный код понятно работать будет быстрее.
Для тех, кому пригодится, выкладываю тестовый проект. Там в папке Release лежит собранный экзешник, для тех у кого нет студии.

Dr_Quake · 09.06.2013, 16:49

Вот видишь - сказал же, проверять полезнее и тесты смотреть - про 32к особенно. А пока чтобы с этим удобно работать мне предстоит 12 студию ставить... 8 проект не понимает, видимо время настало.

@SharpA · 09.06.2013, 19:54 **[ТС]**

Dexiny, большое спасибо за такой подробный разбор полета)) Очень помогли)

@Winhttp22 · 10.06.2013, 11:27

Сообщение от Dexiny

............ Сишный код понятно работать будет быстрее.

а мне кто то говорил, что си наоборот работает медленнее, чем сишарп. Вылаживали тесты, которые это подтверждали. Приведу цитату -

Сообщение от diagon

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

Можно узнать - почему ты считаешь, что си будет работать быстрее?

@Dexiny · 10.06.2013, 12:14

Managed код теоретически не может работать быстрее из-за своей избыточности

Особенно в делах обработки байтов и строк. Если ты написал программу на Си и она работает медленней, то значит ты школьник, который писать код не умеет ) У сишарпа очень медленные строки, даже вставки Unsafe ускоряют в разы код. Regex да, хорошо получился, за счёт того, что он компилируется перед запуском под конкретный процессор. А вот класc Encoding, который занимается применением кодировки к строкам, работает неимоверно медленно. Сишный же код компилируется при создании программы в "машинный" под конкретную архитектуру. Скомпилил под 32 бита библиотеку, на 64 бита не заработает, скомпилил под х86 .... и тд. А вот шарпы это фреймворк, вы используете runtime-компоненты, которые при запуски определяются, связываются, компилятся. Поэтому вы мало беспокоитесь о том, на какой винде и как будет работать код. Вы можете прямо в одной dll определить разные функции для 32 и 64 бит, выбирать их по условию прямо в коде программы.

Да даже недавно соревновались с челом одним, писали архиватор для строк. У него скорости такие получились 900Мб/с сжатие, 1500Мб/с распаковка, с постархивацией скорости упали на 50%, но зато он обошёл все коммерческие архиваторы по степени сжатия (кстати там какой-то рейтинг даже есть алгоритмов на каком-то сайте). Ну а у меня получились скромные 150Мб/с сжатие и 450Мб/с извлечение, и это я использовал Unsafe декодер строк и использовал исходный код 7zip.

@Winhttp22 · 10.06.2013, 12:39

Если ты написал программу на Си и она работает медленней, то значит ты школьник, который писать код не умеет )

ок, вот тебе два примера, один на си, другой на сишарпе, где с++ проигрывает по скорости -
C++ - http://ideone.com/23N3nB (время выполнения - 5.69s )
C# - http://ideone.com/7TTk9l (время выполнения - 5.5s )
Перепиши код, чтобы он выполнялся быстрее.

Сишный же код компилируется при создании программы в "машинный" под конкретную архитектуру.

ну вот я тоже об этом говорил...

@Dexiny · 10.06.2013, 17:42

Это погрешность вывода консольного приложения ) Меряй время без учёта вывода текста на консоль через такты. И кстати типы-значения у шарпа хорошо работают (ну кроме char), как и у любого другого языка, просто не надо по одному лёгкому примеру сравнивать производительность. Да и ещё сравнивать с stdlib сишника, который собирается под любые платформы. Тести boost лучше с аппаратными оптимизациями.

@Winhttp22 · 10.06.2013, 20:01

Это погрешность вывода консольного приложения )

вот оно оказывается как. то ты говорил, что какие-то функции в С# работают слишком медленно (Encoding), то ты уже говоришь, что в С++ какие-то функции тоже работают медленно(функция вывода в консоль). Немогу логики в твоих словах уловить. Я то понимаю, и сам считаю(ну или считал), что шарп работает медленно... и где-то это так и есть , вот пример сортировки массива методом пузырька -
С++ http://ideone.com/QiS0aC (время: 0.18s)
С# http://ideone.com/dUgKRj (время: 0.54s)
так, как я знаю из лекций по си, что обращение к массиву из неуправляемого кода происходит быстрее, чем с управляемого, где время тратится еще на то, что-бы проверить, не вышли ли мы за границы массива...
НО:
в си имеются библиотеки(?), которые работают медленно, как в том же шарпе. И чтобы написать действительно программу, шустрее чем на шарпе - нужно быть как минимум профессионалом, ну или в этом неплохо разбираться, да? Поэтому наверное будет неправильно советовать писать что-то на си, если оно может получиться еще медленнее, в ветке форума - "Форум C# для начинающих", ты как считаешь?

Добавлено через 2 минуты
да и еще мне тут товариш один скидывал цитату из книги, приведу ее -

Кликните здесь для просмотра всего текста

Полезно также знать, что JITкомпилятор CLR оптимизирует машинный код
аналогично компилятору неуправляемого кода C++. И опять же: создание опти
мизированного кода занимает больше времени, но производительность его бу
дет гораздо выше, чем неоптимизированного.
Примечание Есть два параметра компилятора C#, влияющих на опти
мизацию кода — /optimize и /debug. В приведенной ниже таблице пока
зано их влияние на качество ILкода, созданного компилятором C#, и ма
шинного кода, сгенерированного JITкомпилятором.
Разработчики с опытом программирования на неуправляемых C/C++ наверняка
заинтересуются, как это сказывается на производительности. В конце концов,
неуправляемый код компилируется для конкретного процессора и при вызове
просто исполняется. В управляемой же среде компиляция производится в два этапа.
Сначала компилятор проходит исходный код и переводит его в IL. Но для испол
нения сам ILкод нужно перевести в машинные команды в период выполнения,
что требует дополнительной памяти и процессорного времени.
Поверьте: я сам из тех, кто программирует на C/C++, и, переходя на CLR, я до
статочно скептически рассматривал все эти дополнительные издержки. Вторая
стадия компиляции, имеющая место в период выполнения, снижает скорость и
требует дополнительной динамической памяти — с этим не поспоришь. Однако
Microsoft проделала большую работу, чтобы свести эти издержки к минимуму.
Примечание При создании неоптимизированного ILкода компилятор
C# создает в коде команды NOP (nooperation — «пустая команда») — они
нужны для поддержки функции «редактирование и продолжение выпол
нения» в процессе отладки. Также команды NOP облегчают отладку кода
за счет расстановки точек останова на управляющих командах, таких как
for, while, do, if, else, а также блоках try, catch и finally. Предполагают, что
это дополнительная возможность платформы, но лично меня эти коман
дыпустышки часто раздражали, когда при пошаговой отладке кода при
ходилось выполнять их по одной. Создавая оптимизированный код, ком
пилятор C# удаляет команды NOP.
При создании нового проекта на C# в Visual Studio отладочная вер
сия (Debug) собирается с параметрами /optimize и /debug:full, а версия
Release — с параметрами /optimize+ и /debugdbonly.
Впрочем, независимо от этих параметров при подключении отлад
чика кпроцессу, поддерживающему CLR, для облегчения отладки JIT
компилятор всегда создает неоптимизированный машинный код. Ясно,
что производительность такого кода ниже.
14 Часть I Основы CLR
Если вы тоже скептик, сами создайте приложение и проверьте его производи
тельность. Кроме того, можете взять для этих целей какоенибудь нетривиальное
приложение от Microsoft или другого разработчика. Я думаю, вас удивит, насколько
быстродействие высоко на самом деле.
Трудно поверить, но многие (включая меня) считают, что управляемые приложения могут работать производительнее неуправляемых, и тому есть масса
причин. Взять хотя бы тот факт, что превращая ILкод в команды процессора в
период выполнения, JITкомпилятор располагает более полными сведениями о
среде выполнения, чем компилятор неуправляемого кода. Вот особенности, ко
торые позволяют управляемому коду «опередить» неуправляемый.
JITкомпилятор может обнаружить факт выполнения приложения на Pentium 4
и сгенерировать машинный код, полностью использующий все преимущества
особых команд этого процессора. Неуправляемые приложения обычно ком
пилируют в расчете на среднестатистический процессор, избегая специ
фических команд, которые заметно повышают производительность приложе
ния на новейших процессорах.
JITкомпилятор может обнаружить, что определенное выражение на конкрет
ной машине всегда равно false. Например, посмотрим на метод с таким кодом:
if (numberOfCPUs > 1) {
...
}
Здесь numberOfCPUs — число процессоров. Код указывает JITкомпилято
ру, что для машины с одним процессором не нужно генерировать никаких
машинных команд. В этом случае машинный код оптимизирован для конкрет
ной машины: он короче и выполняется быстрее.CLR может проанализировать выполнение кода и перекомпилировать ILкод в
команды процессора во время выполнения приложения. Перекомпилирован
ный код может реорганизовываться с учетом обнаруженных некорректных
прогнозов ветвления.
Это лишь малая часть аргументов в пользу того, что управляемый код будуще
го будет исполняться лучше сегодняшнего неуправляемого. Как я сказал, произ
водительность и сейчас очень неплохая для большинства приложений, а со вре
менем ситуация только улучшится.
Если ваши эксперименты покажут, что JITкомпилятор CLR не обеспечивает
нужную производительность, рекомендую воспользоваться утилитой NGen.exe,
поставляемой с .NET Framework SDK. NGen.exe компилирует весь ILкод выбран
ной сборки в машинный и сохраняет его в дисковом файле. При загрузке сборки
в период выполнения среда CLR автоматически проверяет наличие предварительно
скомпилированной версии сборки и, если она есть, загружает скомпилированный
код, так что компиляция в период выполнения не производится. Заметьте, что
NGen.exe не ориентируется на конкретную среду выполнения и генерирует код
для среднестатистической машины; по этой причине созданный утилитой код не
столь оптимизирован, как произведенный JITкомпилятором. Подробнее об
NGen.exe я расскажу далее.

Dr_Quake · 10.06.2013, 21:31

Это ещё мелочи, вот сейчас 12 студия докачается...

Добавлено через 1 час 29 минут
Докачалась - начал изучать. После

C#
1
2
3
buf = sr.ReadLine() + " ";
                            list_size += buf.Length;
                            list.Add(buf);

чуть не разбил ноутбук фейспалмом и понял что это будет несколько дольше...

@Winhttp22 · 10.06.2013, 21:48

Меряй время без учёта вывода текста на консоль через такты.

а вот и результаты с замерами времени без вывода в консоль -
C++ http://ideone.com/UCmGF2 (Result: -56.4002, time: 0.62)
С# http://ideone.com/wGxj66 (Result: -56.4002292586167, time: 0.512)
И шарп опять быстрее...

Добавлено через 16 минут

Сообщение от Dr_Quake

Докачалась - начал изучать. После

C#
1
2
3
buf = sr.ReadLine() + " ";
                            list_size += buf.Length;
                            list.Add(buf);

чуть не разбил ноутбук фейспалмом и понял что это будет несколько дольше...

сначала бы "Хеллоу ворды" пописал

Тут ничего сложного -

C#
1
2
3
buf = sr.ReadLine() + " "; //чтение строки из файла в переменную buf, и добавление пробела в конец
list_size += buf.Length; // увеличение переменной  list_size , на кол-во знаков переменной buf
list.Add(buf); // добавление в колекцию List  переменной buf

@Dexiny · 10.06.2013, 22:05

Как нистранно регексу легче пробелы отследить, чем искать буквы http в буквах ) Я использовал стандарт, понятное дело, что я не пользуюсь встроенными методами типа ReadLine, но я не собираюсь понтоваться, пишите код, ускоряющий и правильный, посмотрим. Я лишь показываю какие варианты использования регекса могут быть.

Добавлено через 5 минут

Сообщение от Winhttp22

то ты уже говоришь, что в С++ какие-то функции тоже работают медленно(функция вывода в консоль)

У сишника много на самом деле багов ) Не знание их это уже непрофессионализм. А сишарп да, для массы пишут умные люди, чтобы пипл хавал ) Я сам люблю шарп, хоть понимаю, что на сишнике всё бы у меня работало быстрее и правильнее ) Но когда в проекте накапливается 100 файлов с классами, вздыхаю и успокаиваюсь, что это сишарп и я не запутаюсь в этих бесчисленных ашниках.

Dr_Quake · 10.06.2013, 22:09

Сообщение от Winhttp22

а вот и результаты с замерами времени без вывода в консоль -
C++ http://ideone.com/UCmGF2 (Result: -56.4002, time: 0.62)
С# http://ideone.com/wGxj66 (Result: -56.4002292586167, time: 0.512)
И шарп опять быстрее...

Добавлено через 16 минут

сначала бы "Хеллоу ворды" пописал

Тут ничего сложного -

C#
1
2
3
buf = sr.ReadLine() + " "; //чтение строки из файла в переменную buf, и добавление пробела в конец
list_size += buf.Length; // увеличение переменной  list_size , на кол-во знаков переменной buf
list.Add(buf); // добавление в колекцию List  переменной buf

Ты не понял, так писать абсолютно нельзя - динамически выделяя память по строке в time-critical цикле, это даже не быдлокод, это очередное непонимание основ... А потом пишешь что "тесты с блоками32к медленее"
...

@Dexiny · 10.06.2013, 22:13

Сообщение от Dr_Quake

это очередное непонимание основ...

Напиши как правильно, я не понял лично твоего комментария. Исправь код и всё станет ясно (ну 200 метров выжми, будь мужиком).

Добавлено через 1 минуту
И кстати я всегда считал (да и проверял) List<T> это ничто иное как список ссылок.

@Winhttp22 · 10.06.2013, 22:17

Сообщение от Dr_Quake

Ты не понял, так писать абсолютно нельзя - динамически выделяя память по строке в time-critical цикле, это даже не быдлокод, это очередное непонимание основ... А потом пишешь что "тесты с блоками32к медленее"
...

я вообще проект не смотрел. Что ты написал - то я и прокомментировал.

Я сам люблю шарп, хоть понимаю, что на сишнике всё бы у меня работало быстрее и правильнее )

ну я вижу, что ты хочешь сказать, что профессионал, ну или что-то в этом роде, и неплохо разбираешься в си. ОКАУ. Только покажи это не на словах, а на деле - вон у тебя есть код из последнего моего теста, оптимизируй его, чтобы он обогнал шарп. А то ведь ты сам говорил, что проблема в выводе в консоль, а дело то оказалось не в нем.

@Dexiny · 10.06.2013, 22:23

Я работаю программером Си ) Сишарп это скорее хобби ) Ну иногда я пишу тулзы для работы, типа баз данных и парсеров. Просто я работаю не с х86, то есть там физически нет что-то другого кроме сишника.

@Winhttp22 · 10.06.2013, 22:33

Я работаю программером Си

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

Так что вперед

Новые блоги и статьи Все статьи Все блоги /
Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .	Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .
Программа опроса у.з. расходомера SLS-720F Argus19 02.09.2026 Программа опроса у. з. расходомера SLS-720F Программа опрашивает один раз в минуту три ультразвуковых расходомера SLS-720F через интерфейс RS-485 по протоколу Modbus RTU. Опрашиваются регистры. . .	Hyper-V: Компьютер должен поддерживать доверенный платформенный модуль 2.0. Maks 31.08.2026 При установке Windows 11 на виртуальную машину Hyper-V 2-го поколения вылезла такая ошибка: Решение: в параметрах виртуальной машины, в разделе "Безопасность" (Security) активировать флаг. . .	Архитектура биовида Стива в Майнкрафте: Зачем бонобо кубический каннибализм anaschu 30.08.2026 Кубический Вагинокапитализм в Minecraft: Математический инвариант ОДУ и рок Стивов-бонобо Главная задача разработанной «Модели Всего» — наглядно продемонстрировать наличие системной «судьбы». . .	Оттачиваю умение писать js программы. russiannick 30.08.2026 Проектом выходного дня стало написание Книги шифров Виженера. Итогом стала версия 200, синий туман. Синий туман назван так, потому что замораживает текст под собой. Нажатие синих кнопок управляют. . .

@Dexiny 177 / 94 / 10 Регистрация: 27.05.2013 Сообщений: 290
	09.06.2013, 03:47
	откуда разы возьмутся, если время работы Regex 15%, остальное время тратится на декодинг/энкодинг и индексирование строк. Вы просто ниразу не писали таких программ, поэтому понятия не имеете. А толкать умные слова по потокам и массивам любой школьник 3 класса может. Добавлено через 4 минуты Ща короче высплюсь и завтра набросаю профилирование данного кода и анализом его ускорения я же не патентую ничего 0

Dr_Quake Заблокирован
	09.06.2013, 03:49
	Если с VD на другой VD - две линейных операции - столько примерно бонуса и будет, это да. Но из-за малограмотного программиста что будет кто-то такое организовывать итд - да ну нафиг, а руководство этого и не поймёт то... Добавлено через 23 секунды О б-же, да ни при чём тут твой код(кроме, конечно, однопоточного regex)... Всё упирается в IO... 0

Dr_Quake Заблокирован
	09.06.2013, 16:49
	Вот видишь - сказал же, проверять полезнее и тесты смотреть - про 32к особенно. А пока чтобы с этим удобно работать мне предстоит 12 студию ставить... 8 проект не понимает, видимо время настало. 0

@SharpA 2 / 2 / 1 Регистрация: 16.05.2013 Сообщений: 69
	09.06.2013, 19:54 [ТС]
	Dexiny, большое спасибо за такой подробный разбор полета)) Очень помогли) 0

@Dexiny 177 / 94 / 10 Регистрация: 27.05.2013 Сообщений: 290
	10.06.2013, 12:14
	Managed код теоретически не может работать быстрее из-за своей избыточности Особенно в делах обработки байтов и строк. Если ты написал программу на Си и она работает медленней, то значит ты школьник, который писать код не умеет ) У сишарпа очень медленные строки, даже вставки Unsafe ускоряют в разы код. Regex да, хорошо получился, за счёт того, что он компилируется перед запуском под конкретный процессор. А вот класc Encoding, который занимается применением кодировки к строкам, работает неимоверно медленно. Сишный же код компилируется при создании программы в "машинный" под конкретную архитектуру. Скомпилил под 32 бита библиотеку, на 64 бита не заработает, скомпилил под х86 .... и тд. А вот шарпы это фреймворк, вы используете runtime-компоненты, которые при запуски определяются, связываются, компилятся. Поэтому вы мало беспокоитесь о том, на какой винде и как будет работать код. Вы можете прямо в одной dll определить разные функции для 32 и 64 бит, выбирать их по условию прямо в коде программы. Да даже недавно соревновались с челом одним, писали архиватор для строк. У него скорости такие получились 900Мб/с сжатие, 1500Мб/с распаковка, с постархивацией скорости упали на 50%, но зато он обошёл все коммерческие архиваторы по степени сжатия (кстати там какой-то рейтинг даже есть алгоритмов на каком-то сайте). Ну а у меня получились скромные 150Мб/с сжатие и 450Мб/с извлечение, и это я использовал Unsafe декодер строк и использовал исходный код 7zip. 0

@Dexiny 177 / 94 / 10 Регистрация: 27.05.2013 Сообщений: 290
	10.06.2013, 17:42
	Это погрешность вывода консольного приложения ) Меряй время без учёта вывода текста на консоль через такты. И кстати типы-значения у шарпа хорошо работают (ну кроме char), как и у любого другого языка, просто не надо по одному лёгкому примеру сравнивать производительность. Да и ещё сравнивать с stdlib сишника, который собирается под любые платформы. Тести boost лучше с аппаратными оптимизациями. 0

@Dexiny 177 / 94 / 10 Регистрация: 27.05.2013 Сообщений: 290
	10.06.2013, 22:23
	Я работаю программером Си ) Сишарп это скорее хобби ) Ну иногда я пишу тулзы для работы, типа баз данных и парсеров. Просто я работаю не с х86, то есть там физически нет что-то другого кроме сишника. 0