Aplicación GUI de rendimiento crítico (Windows, Linux)

https://stackoverflow.com/questions/9846

08-06-2019
|

Pregunta

Se me ha encomendado la tarea de actualizar una serie de aplicaciones VB.NET de rendimiento crítico que esencialmente solo monitorean y devuelven estadísticas de red.Sólo tengo tres requisitos: conviértalo a C#, hágalo rápido y estable

Una advertencia es que nosotros "puede" migrar de una plataforma .NET a Linux "pronto"

Seré responsable del mantenimiento de estas aplicaciones en el futuro, así que me gustaría hacerlo bien.He decidido refactorizar estas aplicaciones de acuerdo con el patrón MVP para poder realizar pruebas unitarias adecuadas de este chico malo.Pero también estaba pensando que, dado que estaba usando MVP, también podría hacer cosas computacionalmente costosas en código C/C++ nativo, mientras que la GUI se haría con formularios .NET, Qt o lo que sea.

preguntas:

¿Tiene sentido hacer una GUI en Winforms pero las cosas costosas en C/C++ nativo y no administrado?
¿Alguna recomendación para un buen kit de ventanas multiplataforma que se ajuste al escenario descrito anteriormente?

Solución

En primer lugar, dedicaría algo de tiempo a probar algunos Convertidores de VB.NET a C#.Básicamente estás transfiriendo la sintaxis y no hay razón para hacerlo manualmente si no es necesario.Claro, es posible que tengas que limpiar lo que sale del convertidor, pero eso es mucho mejor que una conversión manual.

Ahora, en cuanto a tus preguntas:

1) ¿Tiene sentido hacer una GUI en Winforms pero las cosas costosas en C/C++ nativo y no administrado?

Aún no.Espere hasta que haya realizado la conversión y luego descubra dónde está dedicando realmente su tiempo.No hay razón para lanzarse a mezclar C/C++ con C# hasta que descubra que es necesario.Es posible que descubra que basta con utilizar C# inseguro.Incluso eso puede resultar innecesario.Quizás sólo necesites optimizar los algoritmos.Descubra cuáles son sus obstáculos y entonces decidir cómo solucionarlos.

2) ¿Alguna recomendación para un buen kit de ventanas multiplataforma que se ajuste al escenario descrito anteriormente?

estaría investigando mononucleosis infecciosa con seguridad.Eso es realmente lo mejor que puedes hacer si utilizas C#.Es prácticamente mono u otra reescritura en otro idioma cuando/si pasas a Linux.

Otros consejos

1) La optimización prematura es mala.Implemente sus "cosas caras" en C# y vea si necesita refactorizarlas.O al menos configure una prueba que le permita determinar esto.

2) ¡Guau!Interfaz de usuario multiplataforma.No toleraría eso de "mayo".Clava las comadrejas;¿Cómo es posible tomar decisiones de diseño sin saber lo que estás diseñando?Si opta por una implementación .NET pura, ¿se quejarán si tiene que (como mínimo) refactorizarla para que funcione en Mono?Si lo crea en Java, ¿les molestará que se vea muy feo y los usuarios se quejen de que no pueden encontrar su archivo .exe entre todos esos .jars?

1) No necesariamente.Creo que sería más correcto decir que probablemente valga la pena escribir el código backend en C++, independientemente de las implicaciones en el rendimiento.Aunque no puede obligar a sus superiores a cambiar de plataforma, sería prudente de su parte hacer preparativos para esa eventualidad, ya que los directivos tienden a cambiar de opinión mucho sin una buena razón (o advertencia);Incluso si deciden no cambiar ahora, eso no significa que no decidirán hacerlo dentro de seis meses.Escribir su lógica en C++ ahora, sabiendo que es una posibilidad, aunque más difícil, puede hacer su vida mucho más fácil en el futuro.

2) En realidad no.Hay "soluciones" como wxWindows y GTK#, pero a menudo tienen errores, son difíciles de hacer funcionar correctamente o les falta algo importante en una plataforma u otra.También suelen encerrarte en una interfaz de usuario con el denominador común más bajo (es decir, los controles generales funcionan bien, pero puedes olvidarte de hacer algo interesante (WPF, por ejemplo) con él).Las UI son fáciles de escribir, así que creo que si escribes tu lógica en algo que sea portátil, debería ser una cuestión trivial juntar varias UI específicas de la plataforma.

Para la primera pregunta, es realmente difícil decir si tendría sentido, ya que probablemente dependerá del tipo de rendimiento que necesite obtener.Personalmente, no he visto ninguna desaceleración en todo el sistema debido a la GUI en GUI diseñadas correctamente que utilizan WinForms, por lo que no veo por qué debería causar algún problema y, con toda probabilidad, le haría la vida más fácil con respecto a la GUI. .

En cuanto a su segunda pregunta, si va a pasar a otra plataforma en algún momento, desea echar un vistazo a las bibliotecas que Mono ha implementado (http://www.mono-project.com/Main_Page), esto también debería cubrir la mayoría de sus necesidades con respecto a las ventanas multiplataforma, ya que es compatible con WinForms y GTK#.

No, no tiene sentido hacer "cosas caras" en C/C++.Las posibles mejoras de rendimiento (y muy probablemente menores) nunca superan su productividad, siendo una broma abyecta y enfermiza en comparación con C#.En realidad.Ni siquiera está cerca.

Lea esto (y todas las publicaciones a las que se hace referencia):http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

Es posible que desee considerar el uso Mononucleosis infecciosa.Esta es una versión de código abierto de .NET que se ejecuta en muchas plataformas...Linux,Mac, Solaris, Windows, etc.

Ahora sobre codificar tus cosas caras en C/C++.Aquí hay un artículo que hace un muy buen trabajo explicando las diferencias entre Rendimiento de C/C++ y C#.

Y nuevamente, permítanme enfatizar que el material de C++ es muuuuy caro.¿Tendría sentido hacer lo que mencioné anteriormente?(Formularios .NET que ocultan tareas pesadas de C++)

Como se señaló antes, personalmente no he notado ninguna desaceleración en todo el sistema debido a WinForms en aplicaciones escritas tanto en VB.NET como en C#.Sin embargo, si la aplicación realmente requiere un alto rendimiento, es posible que notes una ligera desaceleración si escribiste todo en C# debido a que está conforme con CIL (http://www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/timestable-demo/).Como tal, escribir la GUI en un lenguaje como C# probablemente facilitará un poco esa parte del desarrollo, lo que le dará más tiempo para trabajar en las partes críticas del código.El único problema aquí es que se pueden notar algunas ralentizaciones debido a las llamadas al código C/C++ desde el código C#;sin embargo, esto es muy poco probable.

1) ¿Tiene sentido hacer una GUI en Winforms pero las cosas costosas en C/C++ nativo y no administrado?

Probablemente no.A menos que se esté comunicando con muchos otros archivos DLL nativos de C o similares, es probable que C# sea entre un 5% y un 5% más lento. más rápido que C++ (std::string realmente te mata si lo estás usando)

2) ¿Alguna recomendación para un buen kit de ventanas multiplataforma que se ajuste al escenario descrito anteriormente?

Si se trata solo de algunos formularios simples con botones, es probable que mono pueda ejecutarlos sin modificaciones.Su soporte para .NET WinForms es bastante bueno hoy en día.Sin embargo, es feo :-)

Puede que esté entendiendo mal el problema., pero si es un sistema de monitoreo de red, ¿por qué no está escrito como un servicio de Windows "dedicado"?

VB.NET no debería ser mucho más lento que C#.No estoy 100% seguro de si hay grandes diferencias en el código IL generado, pero la única ventaja (y una razón justificable para reescribirlo en C#) que se me ocurre (excepto que C# tiene una sintaxis mejor y algunas otras ventajas). ) es el uso de un bloque de código inseguro que podría acelerar un poco las cosas.

Lo de c/c++ puede terminar siendo una buena idea, pero ahora mismo YAGNI.Lo mismo con las cosas de Linux.Ignoralo, no lo vas a necesitar hasta que lo necesites.Quédatelo simple.Prueba unitaria a lo grande, como dices.Haz que el código funcione y evolucionar el diseño desde allí.

Tuve un dilema similar hace algún tiempo, mientras intentaba encontrar la mejor manera de desarrollar una herramienta de prueba de H/W basada en PC (que obviamente significa "con opciones de UI") que interactúe con un hardware integrado (a través de la interfaz PCMCIA).

El cuello de botella fue que la prueba debía ejecutarse con una desviación máxima de 10 ms del tiempo previsto especificado por el evaluador.

P.ej:Si el probador crea la siguiente secuencia de prueba:

el retraso mencionado en el paso 2 no debe ser > 60 ms.

Elegí la aplicación C++ WIN32 como back-end y VC++ 2005 Winform (plataforma .NET) para el desarrollo de la interfaz de usuario.Información detallada sobre cómo interconectar estos dos está disponible en msdn
Segregué el sistema así:
En VC++ .NET:

En C++WIN32:

El sistema completo está en funcionamiento.Parece bastante estable.(Sin la desviación de tiempo mencionada anteriormente).
Tenga en cuenta que la PC de prueba que utilizamos es únicamente para fines de prueba de H/W (solo tenía la interfaz de usuario ejecutándose, sin actualizaciones automáticas, análisis de virus, etc.).etc..).

gtk-nítido es un conjunto de herramientas multiplataforma bastante agradable.

Gtk# es un kit de herramientas de interfaz gráfica de usuario para mono y .Net.El proyecto une el kit de herramientas gtk+ y una variedad de bibliotecas GNOME, lo que permite el desarrollo de aplicaciones Gnome gráficas totalmente nativas utilizando los marcos de desarrollo Mono y .Net.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow