Первое, что мне нужно упомянуть, это то, что код .Net никогда не запускается на виртуальной машине. Несмотря на то, что программы .Net скомпилированы в IL, который в некоторой степени аналогичен Java ByteCode, важное отличие состоит в том, что IL в свою очередь компилируется в полностью нативный код перед запуском приложения, а не интерпретируется виртуальной машиной.
Переход к сравнению .Net / VB6. Я не могу указать конкретные данные, но из личного опыта это зависит от того, что вы делаете.
Чтобы проиллюстрировать это, давайте подумаем о шести различных тестовых приложениях, каждое с версией vb6 и .Net. Каждое приложение выбирает определенную операцию, выполняет ее 100 000 раз, а затем записывает количество времени, которое потребовалось. Обратите внимание, что это мысленный эксперимент: я не видел результатов реальных приложений. Но я чувствую, что чувствую сильные и слабые стороны обеих платформ.
Приложение A выполняет серьезное вычисление с большим количеством процессоров. В этом случае я должен полагать, что результаты здесь будут почти идентичны. И VB6, и .Net компилируются до собственного кода, поэтому инструкция cpu mult одинакова независимо. Тем не менее, если вы не используете Option Strict, вы можете быстро получить проблемы на любой платформе. Поскольку вы использовали C # (по сути, это всегда Option Strict), это может дать вашему .Net коду преимущество.
Приложение B выходит и получает значение из базы данных. Опять же, результаты, вероятно, очень близки, хотя мне пришлось бы дать .Net очень небольшое преимущество по двум причинам: он использует собственный клиент sql, который предположительно немного быстрее, и выполняет такие вещи, как автоматический пул соединений и делает проще выделить такие вещи, как подключение один раз и повторное использование этого подключения, а не повторное подключение. Но если вы сравните яблоки с яблоками в том, что касается кода, они, вероятно, будут очень близки.
Приложение C показывает и скрывает форму несколько раз. Здесь я должен был бы дать vb6 кивок. Он основан на старом, менее блестящем наборе виджетов, который, откровенно говоря, будет дешевле отображать. Кроме того, компоненты WinForms не известны своей быстротой. Тем не менее, разница, вероятно, не так велика, как вы думаете, и вы, вероятно, тоже не полностью перерисовываете формы. Вероятно, это медлительность, на которую жалуются ваши пользователи.
Приложение D основано на строковых операциях, и здесь я должен дать добро .Net. И VB6, и .Net известны медленными строковыми операциями. Однако .Net предоставляет ряд инструментов, которые просто не доступны в vb6, чтобы помочь разработчикам преодолеть медлительность. Тем не менее, если вы не знаете об этих инструментах, неправильный выбор строковых операций может легко затормозить ваше приложение, выполняя бесполезную работу. Это также может привести к жалобам пользователей.
Приложение E будет многократно загружать XML-документ в память. Опять же, я должен думать, что .Net будет иметь преимущество. Прежде всего, инструменты xml, доступные для vb, были в лучшем случае примитивными. Я считаю маловероятным, что они не были значительно улучшены. Кроме того, сборщик мусора .Net довольно умен, предоставляя ему преимущество или выделяя и освобождая память во время загрузки. Тем не менее, я думаю, что самым важным здесь будет скорость диска, а это значит, что разница не будет такой большой.
Приложение F будет многократно запускать программу .Net или vb6, ждать, пока оно станет готовым (для некоторого определения «готово»), и затем закрывать его. Здесь vb6, вероятно, имеет преимущество по двум причинам. Во-первых, .Net должен скомпилировать IL для байт-кода при первом запуске. К счастью, это только первый запуск. В-третьих, приложение .Net также должно загружать любые ссылочные сборки. Для сравнения, время выполнения VB6 на намного меньше. Однако это обычно справедливо только в первый раз, когда вы запускаете приложение на определенной машине, и есть способы предварительной компиляции кода .Net. Это также может способствовать воспринимаемой медлительности.
Одним из важных моментов является то, что для всех этих приложений приложение .Net, вероятно, будет занимать намного больший объем памяти. По некоторым причинам разработчики склонны думать об этом как о плохой характеристике производительности, хотя на самом деле все наоборот. Если ваше приложение использует больше памяти, оно, вероятно, тратит меньше времени на запись на диск, и диск намного медленнее. Это, вероятно, также кеширование больше, что экономит время процессора. А для .Net, в частности, это экономит операции выделения / освобождения для периодов, когда это важнее или когда компьютер бездействует.
У меня нет времени, но было бы интересно увидеть, как кто-то использует реализацию StopWatch (по крайней мере, для .Net), упомянутую в Today Coding Horror , чтобы получить реальные тесты для каждого из них.