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

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

Одно предостережение в том, что мы «можем» перейти с платформы .NET на linux «в ближайшее время».

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

вопросов:

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

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

13.08.2008 14:00:55
12 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

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

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

5
13.08.2008 19:47:04
Обратите внимание на ограниченную поддержку Windows Forms - не все может быть поддержано.
Blaisorblade 16.01.2009 03:58:49

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

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

4
13.08.2008 14:19:25

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

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

2
13.08.2008 14:24:12

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

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

2
13.08.2008 14:27:41

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

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

3
13.08.2008 20:32:39
Ну, такое утверждение о GTK # довольно странно. Я не знаю привязок C #, но GTK + - это очень зрелая платформа для Linux - если вы когда-либо видели рабочий стол Ubuntu, который представляет собой чистый GTK +, и некоторые новые приложения (Beagle) есть в GTK #. Хотя я не знаю WPF.
Blaisorblade 16.01.2009 04:01:25
Да, GTK + - очень зрелая платформа для Linux . На самом деле мы говорим о кроссплатформенном интерфейсе. GTK + это не то. Использование его на Mac - разочаровывающий опыт, и просто получить хорошую сборку на Windows - это феноменальный объем работы по сравнению со всем остальным.
TheSmurf 16.01.2009 17:40:51

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

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

2
13.08.2008 14:34:47
Учитывая, что в статье упоминается набор инструкций HyperThreaded, я думаю, что могут быть более надежные источники.
Blaisorblade 16.01.2009 04:42:08

И еще раз, позвольте мне подчеркнуть, что 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 #; однако, это, вероятно, очень маловероятно.

1
13.08.2008 19:13:50

Возможно, я неправильно понимаю проблему , но если это система сетевого мониторинга, почему она не написана как «выделенная» служба Windows?

VB.NET не должен быть намного медленнее, чем C #. Я не уверен на 100%, есть ли какие-то большие различия в сгенерированном IL-коде, но единственное преимущество (и обоснованная причина переписать его в C #), о котором я мог подумать (за исключением того, что C # имеет более приятный синтаксис и некоторые другие полезности ) - это использование небезопасного блока кода, который может немного ускорить процесс.

0
13.08.2008 19:32:12

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

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

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

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

1
13.08.2008 20:34:21
std :: string тебя убивает? действительно. По сравнению со строками .NET (а обычное удаление и создание новых, которые поощряет сборщик мусора) они очень быстрые. Примечание. Архитекторы WPF не рекомендуют использовать множество строк в коде WPF по соображениям производительности. (Google для веб-трансляции производительности WPF Киран Кумар)
gbjbaanb 17.10.2008 20:22:28

gtk-sharp - очень хороший кроссплатформенный инструментарий.

Gtk # - это набор инструментов для графического интерфейса пользователя для моно и .Net. Проект связывает набор инструментов gtk + и различные библиотеки GNOME, что позволяет полностью разрабатывать графические приложения Gnome с использованием сред разработки Mono и .Net.

0
31.08.2012 16:53:03

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

0
2.10.2008 00:32:43
Использование непортативных библиотек, когда переносимость может быть проблемой? Держите это простым, не относится. При любом разумном выборе стоимость реализации пользовательского интерфейса такая же, как и стоимость переноса. Поддержка WinForms должна быть изучена перед выбором, действительно.
Blaisorblade 16.01.2009 04:05:51
Переносимость может быть проблемой, но это не требование. Это золотое покрытие, чтобы добавить его.
Andrew Cowenhoven 16.01.2009 14:38:03

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

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

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

    1. Удаленно активируйте H / W
    2. Дождитесь задержки 50 мс.
    3. Прочитайте информацию H / W.

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


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

    1. Пользовательский интерфейс, чтобы иметь полную информацию о H / W (считывается через внутреннее приложение) и управлять H / W по требованию. (Кнопки, поле со списком и т. Д. И т. Д.)
    2. Интерфейс для запуска критических по времени тестовых последовательностей (как упомянуто в приведенном выше примере).
    3. Сбор этой информации и построение потока (File-stream) в линейно-временном формате (т. Е. В точном порядке шагов, в которых она должна быть выполнена).
    4. Механизм запуска и встряхивания (путем перенаправления стандартного ввода и стандартного вывода) с фоновым приложением WIN32. Общими ресурсами будут файловые потоки.

В C ++ WIN32:

    1. Интерпретация входного файла-потока.
    2. Взаимодействие с H / W.
    3. Сбор информации из H / W и помещение ее в выходной файл-поток.
    4. Индикация завершения теста в пользовательском интерфейсе (через перенаправленный стандартный вывод).

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

0
9.11.2009 08:50:29