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

https://stackoverflow.com/questions/9846

08-06-2019
|

Вопрос

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

Одно предостережение заключается в том, что мы "май" переход с платформы .NET на linux "скоро"

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

вопросы:

имеет ли смысл создавать графический интерфейс в winforms, но дорогостоящие материалы на родном, неуправляемом C / C ++?
есть какие-нибудь рекомендации по хорошему кросс-платформенному оконному набору, который подходил бы для описанного выше сценария?

Решение

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

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

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

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

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В C ++ WIN32:

Вся система запущена в эксплуатацию.Кажется, он довольно стабилен.(Без упомянутого выше отклонения по времени).
Обратите внимание, что тестовый КОМПЬЮТЕР, который мы используем, предназначен исключительно для Ч / Б тестирования (на нем был запущен только пользовательский интерфейс, без автообновлений, проверки на вирусы и т.д..и т.д..).

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow