Критически важное для производительности приложение с графическим интерфейсом (Windows, Linux)

Question

Мне было поручено обновить серию приложений, которые являются критически важными для приложений VB.NET, которые, по сути, просто отслеживают и возвращают сетевую статистику. У меня только три требования: преобразовать его в C #, сделать его быстрым и стабильным

Одно предостережение: мы "можем" мигрировать с платформы .NET на linux "скоро"

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

вопросы:

1. имеет ли смысл делать GUI в winforms, но дорогой материал в нативном, неуправляемом C / C ++?

2. какие-нибудь рекомендации для хорошего кроссплатформенного оконного комплекта, который бы подходил для сценария, описанного выше?

Answer 1

Прежде всего, я бы потратил некоторое время на то, чтобы опробовать несколько конвертеров VB.NET в C # . Вы в основном переносите синтаксис, и нет причин делать это вручную, если вам не нужно. Конечно, вам, возможно, придется очистить то, что выходит из конвертера, но это лучше, чем ручное преобразование.

Теперь, что касается ваших вопросов:

1) имеет ли смысл делать GUI в winforms, но дорогой материал на нативном, неуправляемом C / C ++?

Пока нет. Подождите, пока вы не выполните преобразование, а затем выясните, где вы на самом деле проводите свое время. Нет причин для смешивания C / C ++ с C #, пока вы не обнаружите, что это необходимо. Вы можете обнаружить, что достаточно зайти в небезопасный C #. Даже это может быть ненужным. Возможно, вам просто нужно оптимизировать алгоритмы. Узнайте, какие у вас узкие места, и затем решите, как их исправить.

2) есть ли какие-нибудь рекомендации для хорошего кроссплатформенного оконного комплекта, подходящего для сценария, описанного выше?

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

Answer 2

1) Преждевременная оптимизация - зло. Реализуйте свои "дорогие вещи" в C # и посмотрите, нужно ли вам их реорганизовать. Или, по крайней мере, настройте тест, который позволит вам определить это.

2) Йоуч. Кроссплатформенный интерфейс. Я бы не стал мириться с "майскими" вещами. Прибить ласки вниз; Как вы можете принимать дизайнерские решения, не зная, что вы разрабатываете? Если вы используете чистую реализацию .NET, будут ли они жаловаться, если вам придется (как минимум) изменить ее работу в Mono? Если вы создадите его на Java, они будут раздражены тем, что это выглядит ужасно, и пользователи жалуются, что не могут найти свой файл .exe среди всех этих файлов .jars?

Answer 3

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

2) Не совсем. Существуют «решения», такие как wxWindows и GTK #, но часто они глючат, или их сложно правильно настроить, или им не хватает чего-то важного на той или иной платформе. Они также обычно блокируют вас в пользовательском интерфейсе с наименьшим общим знаменателем (то есть общие элементы управления работают хорошо, но вы можете забыть о том, чтобы когда-нибудь сделать что-то интересное - например, WPF). Интерфейсы просты в написании, поэтому я думаю, что если вы пишете свою логику в чем-то переносимом, то объединить несколько специфичных для платформы интерфейсов должно быть тривиально.

Answer 4

Возможно, вы захотите использовать Mono . Это версия .NET с открытым исходным кодом, которая работает на многих платформах ... Linux, Mac, Solaris, Windows и т. Д.

Теперь о кодировании ваших дорогих вещей в C / C ++. Вот статья, которая делает очень хорошо работа, объясняющая различия между C / C ++ & C # производительностью .

Answer 5

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

Прочитайте это (и все посты, на которые есть ссылки): http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

Answer 6

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

Что касается вашего второго вопроса, если вы собираетесь перейти на другую платформу в какой-то момент - вы хотите взглянуть на библиотеки, которые были реализованы в Mono (http://www.mono -project.com / Main_Page ), это также должно охватывать большинство ваших потребностей в отношении кроссплатформенного оконного управления, поскольку оно поддерживает WinForms и GTK #.

Answer 7

1) имеет ли смысл делать GUI в winforms, но дорогой материал на нативном, неуправляемом C / C ++?

Скорее всего, нет. Если вы не общаетесь с множеством других собственных C-библиотек и т. Д., C #, вероятно, будет на 5% медленнее до 5% быстрее , чем C ++ (std :: string действительно убивает вас, если вы используя его)

2) есть ли какие-нибудь рекомендации для хорошего кроссплатформенного оконного комплекта, подходящего для сценария, описанного выше?

Если это просто несколько простых форм с кнопками, моно, скорее всего, сможет запускать их без изменений. В настоящее время поддержка .NET WinForms довольно хороша. Это, однако, неприятно: -)

Answer 8

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

Как отмечалось ранее, я лично не заметил каких-либо замедлений во всей системе из-за WinForms в приложениях, написанных как на VB.NET, так и на C #. Однако, если приложение действительно сильно повышает производительность, вы можете заметить небольшое замедление, если вы все написали на C # из-за его соответствия в CIL (http://www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/timestable-demo/). Таким образом, написание GUI на языке, таком как C #, будет скорее всего, эта часть разработки будет немного проще, что даст вам больше времени для работы над критическими частями кода. Единственный улов здесь-22 - это заметное замедление из-за обращений к коду C / C ++ из C # код, однако, это, вероятно, очень маловероятно.

Answer 9

У меня была подобная дилемма некоторое время назад, когда я пытался найти лучший способ разработки инструмента тестирования H / W на базе ПК (который, очевидно, означает «с опциями пользовательского интерфейса»), который взаимодействует со встроенным оборудованием (через интерфейс PCMCIA). .

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

Например: если тестер создает следующую последовательность испытаний:

задержка, указанная в шаге 2, не должна превышать 60 мс.

Я выбрал приложение C ++ WIN32 в качестве внутреннего интерфейса и VC ++ 2005 Winform (платформа .NET) для разработки пользовательского интерфейса. Подробная информация о том, как взаимодействовать с этими двумя, доступна в msdn
Я разделил систему следующим образом:
В VC ++ .NET:

В C ++ WIN32:

Вся система запущена и работает. Вроде бы довольно стабильно. (Без учета упомянутого выше временного отклонения).
Обратите внимание, что используемый нами компьютер для тестирования предназначен исключительно для тестирования H / W (на нем был запущен только пользовательский интерфейс, без автообновлений, поиска вирусов и т. Д. И т. Д.).

Answer 10

C / C ++ может оказаться хорошей идеей, но сейчас YAGNI. То же самое с Linux. Игнорируй это, тебе оно не понадобится , пока оно тебе не понадобится. Держите это просто . Модульное тестирование, как вы говорите. Получите работающий код и развивайте дизайн оттуда.