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

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

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

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

вопросов:

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

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

Ответов (12)

Решение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I had similar dilemma some time back, while trying to find out a best way to develop a PC based H/W Testing tool (which obviously means "with UI options") that interacts with an embedded hardware (via PCMCIA interface).

The bottleneck was that the testing should run at maximum deviation of 10ms from the intended time specified by the tester.

E.g: If the tester creates the following test sequence:

    1. Remotely activate the H/W
    2. Wait for 50ms delay.
    3. Read an H/W information.

the delay mentioned in step 2 should not be > 60ms.


I chose C++ WIN32 application as my back-end and VC++ 2005 Winform (.NET platform) for UI development. Detailed information on how to interface these two is available in msdn
I segregated the system like this:
In VC++ .NET:

    1. UI to have complete information about the H/W (read via back-end application) and to control the H/W on demand. (Buttons, combo-box etc.. etc..)
    2. UI to run time critical test sequences (as mentioned in the above example).
    3. Gathering these information and building a stream (File-stream) in a Time-linear format (i.e, in the precise order of steps in which it has to be performed).
    4. Triggering and hand-shaking mechanism (by redirecting standard input and standard output) with WIN32 back-end application. The common resources will be the File-streams.

In C++ WIN32:

    1. Interpreting the Input File-Stream.
    2. Interaction with H/W.
    3. Gathering information from H/W and putting it in its Output File-Stream.
    4. Indication of test completion to UI (via redirected standard output).

The complete system is up and running. It seems to be pretty stable. (Without the timing deviation mentioned above).
Note that, the testing PC we use is solely for the H/W Testing purpose (it had just the UI running on it, with no auto-updates, virus scan etc.. etc.. ).