Applicazione GUI critica per le prestazioni (Windows, Linux)

https://stackoverflow.com/questions/9846

08-06-2019
|

Domanda

Mi è stato assegnato il compito di aggiornare una serie di applicazioni che sono app VB.NET critiche per le prestazioni che essenzialmente monitorano e restituiscono statistiche di rete.Ho solo tre requisiti: convertilo in C#, rendilo veloce e stabile

Un avvertimento è che noi "Maggio" migrare da una piattaforma .NET a Linux "Presto"

Sarò responsabile della manutenzione di queste app in futuro, quindi mi piacerebbe farlo nel modo giusto.Ho deciso di rifattorizzare queste app secondo il modello MVP in modo da poter testare correttamente l'unità di questo ragazzaccio.Ma stavo anche pensando, dato che stavo usando MVP, che avrei potuto anche fare cose computazionalmente costose nel codice nativo C/C++ mentre la GUI sarebbe stata fatta con moduli .NET, o Qt o altro.

domande:

ha senso realizzare una GUI in Winforms ma le cose costose in C/C++ nativo e non gestito?
qualche consiglio per un buon kit di finestre multipiattaforma adatto allo scenario sopra descritto?

Soluzione

Prima di tutto, vorrei dedicare un po' di tempo a provarne alcuni Convertitori da VB.NET a C#.Fondamentalmente stai eseguendo il porting della sintassi e non c'è motivo di farlo manualmente se non è necessario.Certo, potresti dover ripulire ciò che esce dal convertitore, ma è molto meglio di una conversione manuale.

Ora, per quanto riguarda le tue domande:

1) ha senso realizzare una GUI in Winforms ma cose costose in C/C++ nativo e non gestito?

Non ancora.Aspetta di aver completato la conversione, quindi scopri dove trascorri effettivamente il tuo tempo.Non c'è motivo di lanciarsi nel mixare C/C++ con C# finché non si scopre che è necessario.Potresti scoprire che è sufficiente passare a C# non sicuro.Anche questo potrebbe non essere necessario.Potrebbe essere necessario semplicemente ottimizzare gli algoritmi.Scopri quali sono i tuoi colli di bottiglia e Poi decidere come risolverli.

2) qualche consiglio per un buon kit di finestre multipiattaforma adatto allo scenario sopra descritto?

Ci starei indagando mono di sicuro.Questo è davvero il meglio che puoi fare se usi C#.È praticamente mono o un'altra riscrittura in un'altra lingua quando/se passi a Linux.

Altri suggerimenti

1) L’ottimizzazione prematura è un male.Implementa le tue "cose costose" in C# e verifica se è necessario eseguirne il refactoring.O almeno impostare un test che ti permetta di determinarlo.

2) Va bene.Interfaccia utente multipiattaforma.Non sopporterei la roba del "maggio".Inchioda le donnole;come puoi prendere decisioni di progettazione senza sapere cosa stai progettando?Se utilizzi un'implementazione .NET pura, si lamenteranno se devi (come minimo) effettuare il refactoring per funzionare in Mono?Se lo crei in Java, saranno infastiditi dal fatto che sembra brutto da morire e gli utenti si lamenteranno di non riuscire a trovare il loro file .exe tra tutti quei .jars?

1) Non necessariamente.Penso che sarebbe più corretto dire che probabilmente vale la pena scrivere il codice backend in C++, indipendentemente dalle implicazioni sulle prestazioni.Anche se non puoi vincolare i tuoi superiori al cambio di piattaforma, sarebbe prudente da parte tua prepararti per tale eventualità, dal momento che i tipi di gestione tendono a cambiare spesso idea senza una buona ragione (o preavviso);anche se decidono di non effettuare il passaggio adesso, ciò non significa che non decideranno di effettuare il passaggio tra sei mesi.Scrivere la tua logica in C++ adesso, sapendo che è una possibilità, sebbene più difficile, potrebbe renderti la vita molto più semplice in seguito.

2) Non proprio.Esistono "soluzioni" come wxWindows e GTK#, ma spesso sono difettose o difficili da far funzionare correttamente, oppure mancano qualcosa di importante su una piattaforma o sull'altra.Inoltre, di solito ti bloccano in un'interfaccia utente con il denominatore comune più basso (ovvero, i controlli generali funzionano bene ma puoi dimenticarti di fare qualcosa di interessante, ad esempio WPF, con esso).Le interfacce utente sono facili da scrivere, quindi penso che se scrivi la tua logica in qualcosa che sia portatile, dovrebbe essere una cosa banale mettere insieme diverse interfacce utente specifiche della piattaforma.

Per quanto riguarda la prima domanda, è davvero difficile dire se avrebbe senso poiché probabilmente dipenderebbe dal tipo di prestazioni che devi ottenere.Personalmente non ho riscontrato alcun rallentamento a livello di sistema dovuto alla GUI in GUI adeguatamente progettate utilizzando WinForms, quindi non vedo perché dovrebbe causare problemi e con ogni probabilità ti renderebbe la vita più semplice per quanto riguarda la GUI .

Per quanto riguarda la tua seconda domanda, se ad un certo punto ti sposterai su un'altra piattaforma, vuoi dare un'occhiata alle librerie che sono state implementate da Mono (http://www.mono-project.com/Main_Page), questo dovrebbe anche coprire la maggior parte delle tue esigenze per quanto riguarda le finestre multipiattaforma poiché supporta WinForms e GTK#.

No, non ha senso fare "cose costose" in C/C++.I potenziali (e molto probabilmente minori) miglioramenti delle prestazioni non superano mai e poi mai la produttività, essendo uno scherzo abietto e malato rispetto a C#.Veramente.Non è nemmeno vicino.

Leggi questo (e tutti i post a cui si fa riferimento all'interno):http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

Potresti voler esaminare l'utilizzo Mono.Questa è una versione open source di .NET che funziona su molte piattaforme...Linux,Mac, Solaris, Windows, ecc..

Ora parliamo di codificare le tue cose costose in C/C++.Ecco un articolo che fa un ottimo lavoro che spiega le differenze tra Prestazioni C/C++ e C#.

E ancora, lasciatemi sottolineare, il materiale C++ è moooolto costoso.Avrebbe senso fare quello che ho detto sopra?(Moduli .NET che nascondono C++ pesante)

Come notato prima, personalmente non ho notato alcun rallentamento a livello di sistema dovuto a WinForms nelle applicazioni scritte sia in VB.NET che in C#.Tuttavia, se l'applicazione richiede davvero molte prestazioni, potresti notare un leggero rallentamento se hai scritto tutto in C# perché è conforme a CIL (http://www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/timestable-demo/).Pertanto, scrivere la GUI in un linguaggio come C# renderà probabilmente un po' più semplice quella parte dello sviluppo, il che ti darà più tempo per lavorare sulle parti critiche del codice.L'unico problema qui è che si potrebbero notare alcuni rallentamenti dovuti alle chiamate al codice C/C++ dal codice C#;tuttavia, questo è probabilmente molto improbabile.

1) ha senso realizzare una GUI in Winforms ma cose costose in C/C++ nativo e non gestito?

Molto probabilmente no.A meno che tu non stia comunicando con molte altre DLL C native o così via, è probabile che C# sia tra il 5% più lento e il 5% Più veloce rispetto a C++ (std::string ti uccide davvero se lo usi)

2) qualche consiglio per un buon kit di finestre multipiattaforma adatto allo scenario sopra descritto?

Se si tratta solo di alcuni moduli semplici con pulsanti, mono sarà probabilmente in grado di eseguirli senza modifiche.Il supporto per .NET WinForms è piuttosto buono al giorno d'oggi.Comunque è brutto :-)

Potrei aver frainteso la questione, ma se si tratta di un sistema di monitoraggio della rete, perché non è scritto come servizio Windows "dedicato"?

VB.NET non dovrebbe essere molto più lento di C#.Non sono sicuro al 100% se ci siano grandi differenze nel codice IL generato, ma l'unico vantaggio (e motivo giustificabile per riscriverlo in C#) mi viene in mente (tranne che C# ha una sintassi migliore e alcune altre chicche ) è l'uso di blocchi di codice non sicuri che potrebbero velocizzare un po' le cose.

Le cose c/c++ potrebbero rivelarsi una buona idea, ma in questo momento YAGNI.Lo stesso con le cose su Linux.Ignoralo, non ne avrai bisogno finché non ne avrai bisogno.Tienilo semplice.Provalo a fondo, come dici tu.Fai funzionare il codice e evolvere il design da li.

Ho avuto un dilemma simile qualche tempo fa, mentre cercavo di trovare il modo migliore per sviluppare uno strumento di test H/W basato su PC (che ovviamente significa "con opzioni UI") che interagisce con un hardware incorporato (tramite l'interfaccia PCMCIA).

Il collo di bottiglia era che il test doveva essere eseguito con una deviazione massima di 10 ms dal tempo previsto specificato dal tester.

Per esempio:Se il tester crea la seguente sequenza di test:

il ritardo menzionato al punto 2 non deve essere > 60 ms.

Ho scelto l'applicazione C++ WIN32 come back-end e VC++ 2005 Winform (piattaforma .NET) per lo sviluppo dell'interfaccia utente.Informazioni dettagliate su come interfacciare questi due sono disponibili in msdn
Ho segregato il sistema in questo modo:
In VC++ .NET:

In C++ WIN32:

Il sistema completo è attivo e funzionante.Sembra essere abbastanza stabile.(Senza la deviazione temporale menzionata sopra).
Tieni presente che il PC di test che utilizziamo è esclusivamente a scopo di test H/W (aveva solo l'interfaccia utente in esecuzione, senza aggiornamenti automatici, scansione antivirus, ecc.).eccetera..).

gtk-sharp è un toolkit multipiattaforma piuttosto carino.

Gtk# è un toolkit di interfaccia utente grafica per mono e .Net.Il progetto unisce il toolkit gtk+ e le librerie GNOME assortite, consentendo lo sviluppo di applicazioni Gnome grafiche completamente native utilizzando i framework di sviluppo Mono e .Net.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow