.net - Ydelse kritisk GUI ansøgning (windows, linux)

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg har fået til opgave at opdatere en række applikationer, som er ydeevne kritiske VB.NET apps, der stort set bare overvåger og returnerer netværksstatistikker. Jeg har kun tre krav: konverter det til C #, gør det hurtigt og lav det stabilt


En advarsel er, at vi 'kan' migrere fra en .NET-platform til Linux 'snart'


Jeg vil være ansvarlig for at opretholde disse apps i fremtiden, så jeg vil gerne gøre det rigtige. Jeg har besluttet at refactor disse apps i henhold til MVP-mønstret, så jeg kan korrekt teste helvede ud af denne dårlige dreng. Men jeg tænkte også, siden jeg brugte MVP, at jeg også kunne lave de beregningsmæssigt dyre ting i indfødte C/C ++-kode, mens GUI'en ville blive gjort med .NET-formularer eller Qt eller hvad som helst.


spørgsmål:



  1. giver det mening at lave en GUI i winforms, men de dyre ting i indfødte, ustyrede C/C ++?

  2. Eventuelle anbefalinger til et godt krydsplatformsvinduesæt, der passer til scenariet beskrevet ovenfor?


Bedste reference


For det første vil jeg tage lidt tid på at prøve nogle få VB.NET til C # omformere. Du er grundlæggende havende syntax, og der er ingen grund til at gøre det med hånden, hvis du ikke skal. Sikker på at du måske skal rydde op, hvad der kommer ud af konverteren, men det er bedre end en -hånd konvertering. [1]


Nu, som for dine spørgsmål:



  1) giver det mening at gøre en GUI i winforms, men de dyre ting i indfødte, ustyrede C/C ++?



Ikke endnu. Vent, indtil du har lavet konverteringen, og find ud af, hvor du faktisk bruger din tid. Der er ingen grund til at hoppe ind i blanding C/C ++ med C # indtil du finder ud af at det er nødvendigt. Du kan finde ud af at slippe ind i usikre C # er tilstrækkeligt. Selv det kan være unødvendigt. Du skal muligvis bare optimere algoritmer. Find ud af, hvad dine flaskehalse er, og derefter beslutter, hvordan du retter dem.



  2) nogen anbefalinger til en god cross platform vindue kit, der passer til scenariet beskrevet ovenfor?



Jeg vil sikkert se på mono. Det er virkelig det bedste du kan gøre, hvis du går med C #. Det er stort set hverken mono eller en anden omskrivning på et andet sprog, når/hvis du flytter til Linux. [2]

Andre referencer 1


1) For tidlig optimering er ond. Gennemfør dine 'dyre ting' i C # og se om du skal refactor det. Eller i det mindste oprette en test, der giver dig mulighed for at bestemme dette.


2) Yowch. Cross platform UI. Jeg ville ikke sætte op med 'may' stuffene. Nail vassene ned, hvordan kan du muligvis træffe designbeslutninger uden at vide, hvad du designer? Hvis du går med en ren. NET implementering, vil de klage, hvis du skal (i det mindste) refactor det for at arbejde i Mono? Hvis du opretter det i Java, vil de blive irriteret, at det ser grimt ud som helvede, og brugerne klager over, at de ikke kan finde deres .exe-fil blandt alle disse .jars?

Andre referencer 2


1) Ikke nødvendigvis. Jeg synes, det ville være mere korrekt at sige, at det sandsynligvis er værd at skrive din backend kode i C ++, uanset præstationsimplikationerne. Selvom du ikke kan binde dine high-ups ned på platformskiften, ville det være forsigtigt at Du skal forberede dig på dette eventualitet, da ledelsestyper har en tendens til at ændre sig meget uden god grund (eller advarsel); selvom de beslutter sig for ikke at skifte nu, betyder det ikke, at de vundet, vælger ikke at skifte seks måneder fra nu. Skrive din logik i C ++ nu, vel vidende at det er en mulighed, men vanskeligere, kan gøre dit liv væsentligt nemmere senere.


2) Ikke rigtig. Der er 'løsninger' som wxWindows og GTK #, men ofte er de 'buggy' eller svært at få det til at fungere ordentligt, eller de mangler noget vigtigt på en platform eller en anden. De låser dig også normalt til en lavest fællesnævner. det vil sige, at den generelle kontrol fungerer fint, men man kan glemme, at det nogensinde gør noget interessant - WPF, for eksempel - med det). UI'er er nemme at skrive, så jeg tror, ​​at hvis du skriver din logik i noget, der er bærbart, bør det være et trivielt spørgsmål at slå sammen flere platformspecifikke brugergrænseflader.

Andre referencer 3


For det første spørgsmål er det virkelig svært at sige, om det ville være fornuftigt, da det sandsynligvis vil afhænge af, hvilken type ydeevne du skal have. Jeg har personligt ikke set nogen langsomt systemoverskridelser på grund af GUI'en i korrekt designet GUI'er ved hjælp af WinForms, så jeg kan ikke se hvorfor det ville skulle forårsage nogen problemer, og det ville med al sandsynlighed gøre dit liv lettere med hensyn til GUI'en .


Hvad angår dit andet spørgsmål, hvis du vil flytte til en anden platform på et eller andet tidspunkt - vil du kigge på de biblioteker, der er blevet implementeret af Mono (http://www.mono-project.com/Main\_Page) , dette bør også dække de fleste af dine behov med hensyn til krydsplatformvindue, da det understøtter WinForms og GTK #. [3]

Andre referencer 4


Nej, det giver ikke mening at gøre de 'dyre ting' i C/C ++. De potentielle (og sandsynligvis mindre) ydeevneforbedringer er aldrig større end din produktivitet, der er en uhyggelig, syg vittighed i forhold til C #. Virkelig. Det er ikke engang tæt.


Læs gennem dette (og alle indlæg henvist indenfor):
http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx[4]

Andre referencer 5


Du kan måske se på at bruge Mono. Dette er en open source-version af .NET, der kører på mange pladeformer ... Linux, Mac, Solaris, Windows, osv. [5]


Nu om kodning af dine dyre ting i C/C ++. Her er en artikel, der gør en meget god
job forklarer forskellene mellem C/C ++ & C # ydeevne. [6]

Andre referencer 6



  Og igen, lad mig understrege, at C + + ting er veerrrryyyy dyrt. Ville det være fornuftigt at gøre det, jeg nævnte ovenfor? (.NET formularer skjuler tunge løft C ++)



Som nævnt før har jeg personligt ikke set nogen langsomt nedbrud på grund af WinForms i applikationer skrevet i både VB.NET og C #. Men hvis applikationen er virkelig yderst intensiv, så kan du måske mærke en lille langsom nedgang, hvis du skrev alt i C # på grund af at det overholdes i CIL (http://www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/timestable-demo/). Som sådan skriver du GUI på et sprog som sådan da C # sandsynligvis vil gøre den del af udviklingen lidt lettere, hvilket ville give dig mere tid til at arbejde på de kritiske dele af koden. Den eneste fangst-22 her er muligvis bemærket nogle langsommere som følge af opkaldene til C/C ++ kode fra C # -koden, men det er sandsynligvis meget usandsynligt. [7]

Andre referencer 7



  1) giver det mening at gøre en GUI i winforms, men de dyre ting i indfødte, ustyrede C/C ++?



Mest sandsynligt ikke. Medmindre du kommunikerer med mange andre indfødte C dll'er osv., Vil C # sandsynligvis være mellem 5\% langsommere til 5\% hurtigere end C ++ (std :: string dræber virkelig dig, hvis du ' genbruge det)



  2) nogen anbefalinger til en god cross platform vindue kit, der passer til scenariet beskrevet ovenfor?



Hvis det er bare nogle enkle formularer med knapper, vil mono sandsynligvis kunne køre dem umodificeret. Det er støtte til .NET WinForms er ret godt i disse dage. Det er dog butt grimt :-)

Andre referencer 8


Jeg kan muligvis misforstå problemet , men hvis det er et netværk overvågningssystem, hvorfor er det ikke skrevet som en 'dedikeret' Windows-tjeneste?


VB.NET bør ikke være meget langsommere end C #. Jeg er ikke 100\% sikker på, om der er nogen store forskelle i den genererede IL-kode, men den eneste fordel (og begrundet grund til at omskrive den i C #) kunne jeg tænke på (bortset fra at C # har en pænere syntaks og nogle andre godbidder) er brugen af ​​usikre kodeblok, der kunne fremskynde tingene lidt op.

Andre referencer 9


C/c ++ ting kan ende med at være en god ide, men lige nu YAGNI. Samme med Linux ting. Ignorer det, du behøver det ikke, før du har brug for det. Hold det enkelt. Enhedstest helvede ud af det, som du siger. Få koden til at fungere og udvikle designet derfra. [8] [9] [10]

Andre referencer 10


Jeg havde lignende dilemma noget tid tilbage, mens jeg forsøgte at finde ud af en bedste måde at udvikle et PC-baseret H/W-testværktøj på (som med andre ord betyder 'med brugergrænsefladningsindstillinger'), der interagerer med en indlejret hardware (via PCMCIA-grænsefladen).


Flaskehalsen var, at testen skulle løbe ved maksimal afvigelse på 10 ms fra den påtænkte tid angivet af testeren.


E.g .: Hvis testeren skaber følgende testsekvens:



    1. Fjern aktiveret H/W

    2. Vent på 50ms forsinkelse.

    3. Læs en H/W-information.



forsinkelsen nævnt i trin 2 bør ikke være> 60ms.




Jeg valgte C ++ WIN32 ansøgning som min back-end og VC ++ 2005 Winform (.NET platform) til UI udvikling. Detaljeret information om hvordan man kan interface disse to er tilgængelig i msdn

Jeg adskilt systemet som dette:

I VC ++ .NET: [11]



    1. Brugergrænseflade for at få fuldstændige oplysninger om H/W (læs via back-end-ansøgning) og for at kontrollere H/W efter behov. (Knapper, kombinationsboks osv. Osv.)

    2. Interface til at køre tidskritiske test sekvenser (som nævnt i ovenstående eksempel).

    3. Indsamle disse oplysninger og opbygge en stream (File-stream) i et tidslinjært format (dvs. i den præcise rækkefølge af trin, hvor den skal udføres).

    4. Udløsnings- og håndskakningsmekanisme (ved omdirigering af standardindgang og standardudgang) med WIN32 back-end-applikation. De fælles ressourcer vil være File-streams.


I C ++ WIN32:



    1. Fortolkning af Input File-Stream.

    2. Interaktion med H/W.

    3. Indsamle oplysninger fra H/W og sætte det i sin Output File-Stream.

    4. Angivelse af testafslutning til brugergrænseflade (via omdirigeret standardudgang).



Det komplette system er i gang. Det ser ud til at være ret stabilt. (Uden ovennævnte tidsafvigelse).


Bemærk, at den test-pc, vi bruger, udelukkende er til brug for H/W Testing-formålet (det var bare brugergrænsefladen der kørte på den uden nogen automatiske opdateringer, virusscanning osv. Osv.).

Andre referencer 11


gtk-sharp er en temmelig flot cross platform toolkit. [12]



  Gtk # er et grafisk brugergrænsefladeværktøj til mono og .Net. Projektet binder gtk + værktøjssætet og forskellige GNOME biblioteker, hvilket muliggør fuldt indbygget grafisk Gnome applikationsudvikling ved hjælp af Mono og. Net udviklingsrammerne.