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

Да можно, но сборщик мусора вашим пожеланиями не управляется. Это в некоторых игрушках на C# хорошо видно, когда игровой процесс замораживается на какое-то время, сразу ясно что GC сейчас работает.

Алексей КСдаётся мне, что тормоза .Net к наличию JIT не имеют никакого отношения...

JIT это не единственная причина, по-которой управляемые приложения медленнее нативных. Тут еще огромный слой библиотек над нативным Win32/64 API. Это когда вызываешь функцию .NET а она обертка над WinAPI функцией. Но можно сразу вызывать WinAPI напрямую не пользуясь какой-то там .NET прокладкой. Экономить время и ресурсы.
Это и дурацкие, не отключаемые в .NET проверки переполнения переменных, выходы за границы массивов и т.д. Понятно, что для школьника и студента такие проверки необходимы, но профи в нативных языках всегда выключает эти проверки, чтобы ускорить работу кода и ничего, все как-то работает.

Алексей КО недостатках сказал, теперь самое время поговорить о преимуществах.

Преимущества:

- Простота и дешевизна разработки (почти как на VBA или 1С)
- не нужно управлять памятью (GC)
- не нужно освобождать ресурсы (GC)
- не нужно учитывать разрядность платформы (AnyCPU)
- не нужно изучать UI (всегда можно накидать контролов в WinForms)
- не нужно изучать WinAPI (есть толстая прокладка .NET)
- не нужно учиться работать с указателями (это же небезопасно!)
- не нужно возится с ключами оптимизацией (есть галочка Optimize Code)
- не нужно писать ассемблерные вставки (это же слишком сложно)
- etc

AxeleronEolt,
И какой смысл тогда вообще использовать managed код? Или есть вера в то, что его придумали только для студентишек?

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

Алексей КИ сколько там потребляет эта "обёртка"? Например, в WinForms основные тормоза связаны с отрисовкой через GDI+. Этот факт, научно доказанный много лет назад, к .Net не имеет никакого отношения.

Я не знаю сколько она потребляет. Не замерял. Я всего лишь расстроенный пользователь .Net приложений, которого печалит медленный и неотзывчивый GUI от .NET. У меня есть комп на i7 с 16 Гигами оперативки, вот на этой машине дотнетовские приложения ведут себя прилично. Почти не тормозят. Но у многих пользователей на компах обычные Celeron с 2-4 гигами оперативки и 32-битной версией Windows, вот там торможение управляемого кода очень четко заметно. Даже выполнение обычных операций в UI приводит к замедленному отклику приложения. Например нажимая кнопку Открытия файла на риббоне, я ожидаю появление стандартного окна открытия файла почти сразу, как это происходит в нативных приложениях написанных на C++, и меня расстраивает, когда это окно в шарповом приложении прорисовывается через 5 секунд, со скрипом жесткого диска и кучей сожраной памяти. Печально, когда вывод окна предосмотра печати с содержимым занимает на управляемом приложении секунд 5-10, ведь в нативном приложении оно отрисовывается мгновенно.


автор"Профи" гораздо важнее надёжность программы, чем незначительный прирост производительности.

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