Насколько быстрее C++ , чем C#?

C# может быть не быстрее, но это делает вас/меня быстрее. Это самая важная мера для того, что я делаю. :)

Это на пять апельсинов быстрее. Или, скорее: не может быть (правильного) общего ответа. C++ - это статически скомпилированный язык (но тогда есть и профильная оптимизация), C# работает с помощью JIT-компилятора. Существует так много различий, что на такие вопросы, как "насколько быстрее", нельзя ответить, даже давая порядки величины.

по моему опыту (и я много работал с обоими языками), основная проблема с C# по сравнению с C++ - это высокое потребление памяти, и я не нашел хорошего способа ее контролировать. Это было потребление памяти, которое в конечном итоге замедлит программное обеспечение .NET.

другим фактором является то, что JIT-компилятор не может позволить себе слишком много времени для расширенной оптимизации, потому что он работает во время выполнения, и конечный пользователь заметит это, если это займет слишком много времени. С другой стороны, C++ компилятор имеет все время, необходимое для оптимизации во время компиляции. Этот фактор гораздо менее значим, чем потребление памяти, ИМХО.

Я собираюсь начать с несогласия с частью принятого (и хорошо поддержанного) ответа на этот вопрос, заявив:

на самом деле существует множество причин, по которым JITted-код будет работать медленнее, чем правильно оптимизированный C++ (или другой язык без накладных расходов во время выполнения) программа в том числе:

• вычислительные мощности тратятся на JITting код во время выполнения, по определению, недоступны для использования в программе исполнение.

• любые горячие пути в Джиттере будут конкурировать с вашим кодом для инструкций и кэша данных в ЦП. Мы знаем, что кэш доминирует, когда дело доходит до производительности, и родные языки, такие как C++, по определению не имеют такого типа разногласий.

• бюджет времени оптимизатора времени выполнения обязательно много более ограниченный, чем у оптимизатора времени компиляции (как указал другой комментатор out)

итог: в конечном счете, вы будет почти наверняка сможете создать более быструю реализацию на C++, чем в C#.

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

Это очень длинная и сложная тема, но я считаю, что стоит упомянуть для полноты, что оптимизатор времени выполнения C#превосходен и способен выполнять определенные динамические оптимизации во время выполнения, которые просто недоступны для C++ с его оптимизатором времени компиляции (статическим). Даже при этом преимущество по-прежнему, как правило, глубоко в суде родного приложения, но динамический оптимизатор является причиной "почти конечно " квалификатор, приведенный выше.

--

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

огромная часть проблемы с этими тестами заключается в том, что вы не можете писать код C++, как если бы вы писали C# и ожидали получить репрезентативные результаты (например. выполнение тысяч памяти распределения в C++ дадут вам ужасные цифры.)

1) используемый вектор:: reserve ()

2) сгладил 2d-массив до 1d для достижения лучшей локальности кэша (смежный блок)

C# (.NET 4.6.1)

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);
}

время выполнения (выпуск): Init: 124ms, заполнение: 165ms

C++14 (Clang v3.8 / C2)

#include <iostream>
#include <vector>

auto TestSuite::ColMajorArray()
{
    constexpr size_t ROWS = 5000;
    constexpr size_t COLS = 9000;

    auto initStart = std::chrono::steady_clock::now();

    auto arr = std::vector<double>();
    arr.reserve(ROWS * COLS);

    auto initFinish = std::chrono::steady_clock::now();
    auto initTime = std::chrono::duration_cast<std::chrono::microseconds>(initFinish - initStart);

    auto fillStart = std::chrono::steady_clock::now();

    for(auto i = 0, r = 0; r < ROWS; ++r)
    {
        for (auto c = 0; c < COLS; ++c)
        {
            arr[i++] = static_cast<double>(r * c);
        }
    }

    auto fillFinish = std::chrono::steady_clock::now();
    auto fillTime = std::chrono::duration_cast<std::chrono::milliseconds>(fillFinish - fillStart);

    return std::make_pair(initTime, fillTime);
}

время выполнения (выпуск): Init: 398μs (да, это микросекунды), заполнение: 152ms

Общее время выполнения: C#: 289ms, C++ 152ms (примерно на 90% быстрее)

замечания

• изменение реализации C# на ту же реализацию массива 1D данный Init: 40ms, Fill: 171ms, всего: 211ms (C++ все еще был почти На 40% быстрее!--6-->).

• гораздо сложнее разработать и написать "быстрый" код на C++, чем написать "обычный" код на любом языке.

• (возможно) удивительно легко получить низкую производительность в C++; мы видели, что с неограниченной производительностью векторов. И таких ловушек много.

• производительность C#довольно удивительна, когда вы рассматриваете все, что происходит во время выполнения. И это представление сравнительно легко к доступ.

• более анекдотические данные, сравнивающие производительность C++ и c#: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=csharpcore

суть в том, что c++ дает вам гораздо больше контроля над производительностью. Вы хотите использовать указатель? Ссылку? Память стека? Куча? Динамический полиморфизм или исключение накладных расходов времени выполнения vtable со статическим полиморфизм (через шаблоны / CRTP)? В C++ вы должны... э,получить сделайте все эти выборы (и многое другое) самостоятельно, в идеале, чтобы ваше решение наилучшим образом решало проблему, которую вы решаете.

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

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

в целом, инкапсуляция и отложила принятие решений-это хорошо, потому что это делает код более динамичны, легче адаптируются к изменяющимся требованиям и проще использовать в качестве основы. Вот почему объектно-ориентированное программирование на C# очень продуктивно и может быть обобщено под термином "обобщение". К сожалению, этот конкретный вид обобщения обходится дорого во время выполнения.

обычно эта стоимость несущественна, но есть приложения, где накладные расходы на вызовы виртуальных методов и создание объектов могут иметь значение (тем более, что виртуальные методы предотвращают другие оптимизации, такие как вызов метода inlining). Здесь C++ имеет огромное преимущество, потому что вы можете использовать шаблоны для достижения другого вида обобщения, которое имеет нет влияние на время выполнения, но не обязательно менее полиморфно, чем ООП. Фактически, все механизмы, составляющие ООП, можно смоделировать, используя только методы шаблонов и разрешение во время компиляции.

в таких случаях (и, по общему признанию, они часто ограничены специальными проблемными доменами), C++ выигрывает против C# и сопоставимых языков.

в C++ (или C, если на то пошло) дает вам точный контроль над вашей структуры данных. Если вы хотите bit-twiddle, у вас есть этот вариант. Большие управляемые приложения Java или .NET (OWB,Visual Studio 2005), которые используют внутренние структуры данных библиотек Java/.NET, несут багаж с ними. Я видел сеансы owb designer, использующие более 400 МБ ОЗУ и ставки для cube или ETL дизайн, попадающий в 100-х МБ, а также.

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

IMO в больших приложениях разница заключается не столько в JIT, сколько в структурах данных, которые использует сам код. Там, где приложение является тяжелым для памяти, вы получите менее эффективное использование кэша. Пропуски кэша на современных процессорах довольно дороги. Где C или c++ действительно выигрывают, где вы можете оптимизировать использование структур данных для играйте красиво с кешем CPU.

для графики стандартный класс графики C# намного медленнее, чем GDI, доступ к которому осуществляется через C/C++. Я знаю, что это не имеет ничего общего с языком как таковым, больше с общей платформой .NET, но графика-это то, что предлагается разработчику в качестве замены GDI, и его производительность настолько плоха, что я бы даже не осмелился делать графику с ней.

У нас есть простой тест, который мы используем, чтобы увидеть, как быстро графическая библиотека, и это просто рисование случайных линий в окне. C++ / GDI все еще snappy с 10000 линиями, в то время как C#/графика имеет трудности с 1000 в режиме реального времени.

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

1. когда произойдет GC?

2. сколько времени займет?

Это недетерминированные.

нам пришлось определить, сопоставим ли C# С C++ по производительности, и я написал для этого несколько тестовых программ (используя Visual Studio 2005 для обоих языков). Оказалось, что без сборки мусора и только с учетом языка (а не фреймворка) C# имеет в основном ту же производительность, что и c++. Распределение памяти в C# происходит быстрее, чем в C++, и C# имеет небольшое преимущество в детерминизме, когда размеры данных увеличиваются за пределами границ строки кэша. Тем не менее, все это в конечном итоге оплачивается и существует огромная стоимость в виде недетерминированных хитов производительности для C# из-за сбора мусора.

Как обычно, это зависит от приложения. Есть случаи, когда C#, вероятно, незначительно медленнее, и другие случаи, когда C++ в 5 или 10 раз быстрее, особенно в случаях, когда операции могут быть легко SIMD'D.

Я знаю, что это не то, что вы просили, но C# часто быстрее написать чем C++, что является большим бонусом в коммерческой обстановке.

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

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

C / C++ может работать намного лучше в программах, где есть большие массивы или тяжелые циклы / итерации по массивам (любого размера). Это причина того, что графика в C/C++, как правило, намного быстрее, потому что тяжелые операции массива лежат в основе почти всех графических операций. .NET, как известно, медленна в операциях индексирования массивов из-за всех проверок безопасности, и это особенно верно для многомерных массивов (и, да, прямоугольные массивы C# еще медленнее, чем зубчатые C# матрицы.)

бонусы C / C++ наиболее выражены, если вы придерживаетесь непосредственно указателей и избежать повышения,std::vector и другие контейнеры высокого уровня, а также inline каждая небольшая функция возможна. Используйте массивы старой школы, когда это возможно. Да, вам понадобится больше строк кода для выполнения того же, что и в Java или C#, поскольку вы избегаете контейнеров высокого уровня. Если вам нужен массив динамического размера, вам просто нужно будет не забыть выполнить сопряжение new T[] С соответствующим delete[] заявление (или использовать std::unique_ptr) - цена за дополнительную скорость заключается в том, что вы должны кодировать более тщательно. Но в обмен вы избавляетесь от накладных расходов на сборщик управляемой памяти / мусора, которые могут легко составлять 20% или более времени выполнения сильно объектно-ориентированных программ как в Java, так и в .NET, а также от этих огромных затрат на индексирование массива управляемой памяти. Приложения C++ также могут воспользоваться некоторыми отличными коммутаторами компилятора в определенных конкретных случаях.

Я эксперт программист на C, C++, Java и c#. Недавно у меня был редкий случай реализовать точно такую же алгоритмическую программу на последних 3 языках. В программе было много математических и многомерных операций с массивами. Я сильно оптимизировал это на всех 3 языках. результаты были типичными для того, что я обычно вижу в менее строгих сравнениях: Java была примерно на 1.3 x быстрее, чем C# (большинство JVMs более оптимизированы, чем CLR), а версия необработанного указателя c++ появилась примерно на 2.1 x быстрее, чем С.# обратите внимание, что программа c# использовала только безопасный код-по моему мнению, вы также можете закодировать его на C++ перед использованием unsafe ключевое слово.

чтобы никто не подумал, что я имею что-то против C#, я закончу, сказав, что C#, вероятно, мой любимый язык. Это самый логичный, интуитивно понятный и быстрый язык разработки, с которым я сталкивался до сих пор. Я делаю все свои прототипы на C#. Язык C# имеет много небольших, тонких преимуществ перед Java (да, я знаю, что у Microsoft была возможность исправьте многие недостатки Java, войдя в игру поздно и, возможно, скопировав Java). Тост За Java Calendar класса кто-нибудь? Если Microsoft когда-либо потратит реальные усилия на оптимизацию среды CLR и дрожания .NET, C# может серьезно взять на себя. Я честно удивлен, что они еще этого не сделали-они сделали так много вещей прямо на языке C#, почему бы не продолжить его оптимизацией компилятора? Может, если мы все будем умолять.

> от того, что я слышал ...

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

Как вы собираетесь решить, являются ли вещи, которые люди говорят здесь более или менее правдоподобными, чем то, что вы первоначально слышали?

один из способов-попросить доказательства.

когда кто-то утверждает ,что " есть некоторые области, в которых C# оказывается быстрее, чем c++" задать их почему говорят, что, попросите их показать вам измерения, попросите их показать вам программы. Иногда они просто ошибаются. Иногда вы обнаружите, что они просто выражают мнение, а не делятся чем-то, что они могут показать, что это правда.

часто информация и мнение будут смешаны в том, что люди утверждают, и вам придется попробовать и разобраться, что есть что. Для пример из ответов на этом форуме:

• "взять ориентиры на http://shootout.alioth.debian.org/ с большим скептицизмом, как в основном тест арифметический код, который, скорее всего, не похож на ваш код вообще."

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

• "Это довольно бесполезный тест, поскольку это действительно зависит от того, насколько хорошо индивидуальные программы оптимизирован; мне удалось ускорить некоторые из них в 4-6 раз и более, давая понять, что сравнение между неоптимизированными программами довольно глупый."

  спросите себя, есть ли у автора на самом деле я показал тебе, что он справляется. чтобы "ускорить некоторые из них по 4-6 times or more" - это простое требование сделать!

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

Я сомневаюсь, что это делается .NET или любой из JREs, но это было исследовано еще когда я был в университете, поэтому неразумно думать, что такие вещи могут найти свой путь в реальное мир в какой-то момент скоро.

для "смущающе параллельных" проблем при использовании Intel TBB и OpenMP на C++ я наблюдал примерно 10-кратное увеличение производительности по сравнению с аналогичными (чисто математическими) проблемами, выполненными с C# и TPL. SIMD - одна из областей, где C# не может конкурировать, но у меня также сложилось впечатление, что TPL имеет значительные накладные расходы.

тем не менее, я использую C++ только для критически важных задач, где я знаю, что смогу многопоточно и быстро получить результаты. Для всего остального C# (и иногда F#) является только штраф.

Это очень расплывчатый вопрос без однозначных ответов.

например; я бы предпочел играть в 3D-игры, созданные на C++ , чем на C#, потому что производительность, безусловно, намного лучше. (И я знаю XNA и т. д., но это никоим образом не приближается к реальной вещи).

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

приложения, требующие интенсивного обращения к памяти, например. манипуляции с изображениями обычно лучше писать в неуправляемой среде (c++), чем управляемой (c#). Оптимизированные внутренние петли с арифметикой указателей намного проще контролировать в C++. В C# вам может потребоваться прибегнуть к небезопасному коду, чтобы даже приблизиться к той же производительности.

Я проверил vector в эквиваленте C++ и c# -List и простые 2D-массивы.

Я использую выпуски Visual C#/C++ 2010 Express. Оба проекта-простые консольные приложения, я тестировал их в стандартном (без пользовательских настроек) режиме выпуска и отладки. Списки c# работают быстрее на моем ПК, инициализация массива также быстрее в C#, математические операции медленнее.

Я использую Intel Core2Duo P8600@2.4GHz, C# - .NET 4.0.

Я знаю, что реализация вектора отличается от списка C#, но я просто хотел проверить коллекции, которые я бы использовал для хранения моих объектов (и иметь возможность использовать метод доступа к индексу).

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

C++ векторный тест:

static void TestVector()
{
    clock_t start,finish;
    start=clock();
    vector<vector<double>> myList=vector<vector<double>>();
    int i=0;
    for( i=0; i<500; i++)
    {
        myList.push_back(vector<double>());
        for(int j=0;j<50000;j++)
            myList[i].push_back(j+i);
    }
    finish=clock();
    cout<<(finish-start)<<endl;
    cout<<(double(finish - start)/CLOCKS_PER_SEC);
}

тест списка C#:

private static void TestVector()
{

    DateTime t1 = System.DateTime.Now;
    List<List<double>> myList = new List<List<double>>();
    int i = 0;
    for (i = 0; i < 500; i++)
    {
        myList.Add(new List<double>());
        for (int j = 0; j < 50000; j++)
            myList[i].Add(j *i);
    }
    DateTime t2 = System.DateTime.Now;
    Console.WriteLine(t2 - t1);
}

C++ - array:

static void TestArray()
{
    cout << "Normal array test:" << endl;
    const int rows = 5000;
    const int columns = 9000;
    clock_t start, finish;

    start = clock();
    double** arr = new double*[rows];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    finish = clock();

    cout << (finish - start) << endl;

    start = clock();
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i * j;
    finish = clock();

    cout << (finish - start) << endl;
}

C# - массив:

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i * j;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

}

Время: (Релиз/Отладка)

C++

• 600 / 606 МС массив init,
• 200 / 270 МС заполнение массива,
• init & fill вектора 1sec /13sec.

(Да, 13 секунд, у меня всегда есть проблемы со списками/векторами в режиме отладки.)

C#:

• 20 / 20 мс массив init,
• массив 403 / 440 МС наполни,
• 710 / 742 МС список init & fill.

Ну, это зависит от. Если байт-код переведен в машинный код (а не только JIT) (я имею в виду, если вы выполняете программу) и Если ваша программа использует много выделение/освобождение, это может быть быстрее, потому что GC алгоритм нужен только один проход (теоретически) через всю память только один раз, но нормальные функции malloc/realloc/бесплатно C/C++ называет причины оверхед на каждый вызов (вызов-накладные, структуры данных, кэш-промахов ;) ).

Так это теоретически возможно (также для других языков GC).

Я действительно не вижу крайнего недостатка в том, чтобы не иметь возможности использовать метапрограммирование С C# для большинства приложений, потому что большинство программистов не используют его в любом случае.

еще одним большим преимуществом является то, что SQL, как LINQ "расширение", дает возможность компилятору оптимизировать вызовы баз данных (другими словами, компилятор может скомпилировать весь LINQ в один двоичный файл "blob", где вызываемые функции встроены или оптимизированы для вашего использования, но я спекулирую здесь).

Я полагаю, что есть приложения, написанные на C#, работающие быстро, а также есть больше приложений, написанных на C++, работающих быстро (ну, C++ просто старше... и возьмите UNIX тоже...)
- вопрос действительно в том-на что жалуются пользователи и разработчики ...
Ну, ИМХО, в случае C# у нас очень удобный UI, очень хорошая иерархия библиотек и вся интерфейсная система CLI. В случае C++ у нас есть шаблоны, ATL, COM, MFC и весь shebang alreadyc написаны и запуск кода, такого как OpenGL, DirectX и так далее... Разработчики жалуются на неопределенно возросшие вызовы GC в случае C# (значит программа работает быстро, а через секунду - Бах! он застрял).
Писать код на C# очень просто и быстро (не забывать, что также увеличивают вероятность ошибок. В случае с C++ разработчики жалуются на утечки памяти, - значит давит, звонки между DLL, а также" DLL hell " - проблема с поддержкой и заменой библиотек более новыми...
Я думаю, что больше мастерства вы будете имейте в языке программирования, тем больше качество (и скорость) будет характеризовать ваше программное обеспечение.

Я бы сказал так: программисты, которые пишут более быстрый код,-это те, кто более информирован о том, что заставляет текущие машины работать быстро, и, кстати, они также используют соответствующий инструмент, который позволяет использовать точные низкоуровневые и детерминированные методы оптимизации. По этим причинам эти люди используют C / C++, а не C#. Я бы даже сказал, что это факт.

Если я не ошибаюсь, шаблоны C# определяются во время выполнения. Это должно быть медленнее, чем шаблоны времени компиляции C++.

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

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

вердикт:

• C#: более быстрое развитие, более медленный бег

• C++: медленная разработка, более быстрый запуск.

> в конце концов, ответы должны быть где-то, не так ли? :)

МММ, нет.

Как отмечалось в нескольких ответах,вопрос по указанной в стороны, что вызывает вопросы в ответ, а не ответы. Взять только один путь:

• вопрос объединяет язык с реализацией языка - эта программа на языке C является как 2,194 раза медленнее и 1,17 раза быстрее чем это C# программа - мы должны спросить вас:какие языковые реализации?

и какие программы? Какая машина? Какая ОС? Набор данных?

Это действительно зависит от того, что вы пытаетесь достичь в вашем коде. Я слышал, что это просто материал городской легенды, что есть какая-то разница в производительности между VB.NET, C# и управляемый C++. Тем не менее, я обнаружил, по крайней мере, в строковых сравнениях, что управляемый C++ бьет штаны C#, который, в свою очередь, бьет штаны VB.NET.

Я никоим образом не делал исчерпывающих сравнений в алгоритмической сложности между языками. Я также просто использую значение по умолчанию настройки на каждом из языков. В VB.NET я использую настройки, чтобы требовать объявления переменных и т. д. Вот код, который я использую для управляемого C++: (как вы можете видеть, этот код довольно прост). Я запускаю то же самое на других языках в Visual Studio 2013 с .NET 4.6.2.

#include "stdafx.h"

using namespace System;
using namespace System::Diagnostics;

bool EqualMe(String^ first, String^ second)
{
    return first->Equals(second);
}
int main(array<String ^> ^args)
{
    Stopwatch^ sw = gcnew Stopwatch();
    sw->Start();
    for (int i = 0; i < 100000; i++)
    {
        EqualMe(L"one", L"two");
    }
    sw->Stop();
    Console::WriteLine(sw->ElapsedTicks);
    return 0;
}

вот в C# код:

for (int i=0; i<1000; i++)
{
    StreamReader str = new StreamReader("file.csv");
    StreamWriter stw = new StreamWriter("examp.csv");
    string strL = "";
    while((strL = str.ReadLine()) != null)
    {
        ArrayList al = new ArrayList();
        string[] strline = strL.Split(',');
        al.AddRange(strline);
        foreach(string str1 in strline)
        {
            stw.Write(str1 + ",");
        }
        stw.Write("\n");
    }
    str.Close();
    stw.Close();
}

string array и arraylist используются специально для включения этих инструкций.

вот код c++:

for (int i = 0; i<1000; i++)
{
    std::fstream file("file.csv", ios::in);
    if (!file.is_open())
    {
        std::cout << "File not found!\n";
        return 1;
    }

    ofstream myfile;
    myfile.open ("example.txt");
    std::string csvLine;

    while (std::getline(file, csvLine))
    {
        std::istringstream csvStream(csvLine);
        std::vector csvColumn;
        std::string csvElement;

        while( std::getline(csvStream, csvElement, ‘,’) )
        {
            csvColumn.push_back(csvElement);
        }

        for (std::vector::iterator j = csvColumn.begin(); j != csvColumn.end(); ++j)
        {
            myfile << *j << ", ";
        }

        csvColumn.clear();
        csvElement.clear();
        csvLine.clear();
        myfile << "\n";
    }
    myfile.close();
    file.close();
}

размер входного файла, который я использовал, был 40 КБ.

и вот результат -

• код C++ выполняется за 9 секунд.
• C# код: 4 секунды!!!

О, но это было на Linux... С C# работает на моно... И C++ с g++.

хорошо, это то, что я получил на Windows – Visual Studio 2003:

• C# код, пробежал за 9 секунд.
• код C++ - ужасные 370 секунд!!!