Crítica do desempenho aplicação de interface gráfica (windows,linux)

https://stackoverflow.com/questions/9846

08-06-2019
|

Pergunta

Eu tenho a tarefa com a atualização de uma série de aplicativos que estão com desempenho crítico VB.NET apps que, essencialmente, apenas o monitor e voltar rede estatísticas.Eu tenho somente três requisitos: convertê-lo para C#, torná-lo rápido, e torná-lo estável

Uma ressalva é que nós "talvez" migrar de um .NET plataforma para linux "em breve"

Eu vou ser responsável por manter esses apps no futuro, então eu gostaria de fazer isso direito.Eu tenho decidiu reestruturar a estas aplicações, de acordo com o padrão MVP para que eu possa adequadamente o teste de unidade o inferno fora deste menino mau.Mas eu também estava pensando em como eu estava usando o MVP que eu também poderia fazer o computacionalmente caro em C/C++ nativo de código enquanto o GUI iria ser feito .NET formulários, ou Qt ou o que seja.

perguntas:

faz sentido fazer uma GUI em winforms, mas as coisas caras nativo não gerido e C/C++ ?
quaisquer recomendações para uma boa plataforma cruzada de janelas kit que caberia para o cenário descrito acima?

Solução

Primeiramente, eu gostaria de colocar algum tempo para experimentar alguns VB.NET a C# conversores.Você está basicamente portar sintaxe, e não há nenhuma razão para que pela mão, se você não precisa.Com certeza, você pode ter que limpar o que sai do conversor, mas que é muito melhor do que um por-mão de conversão.

Agora, quanto a suas perguntas:

1) faz sentido fazer uma GUI em winforms, mas as coisas caras nativo não gerido e C/C++ ?

Ainda não.Esperar até que tenha feito a conversão, e, em seguida, descobrir onde você está, na verdade, gastando seu tempo.Não há nenhuma razão para pular na mistura C/C++ e C# até que você descubra que é necessário.Você pode achar que cair em inseguro C# é suficiente.Mesmo que podem ser desnecessários.Você só precisa otimizar algoritmos.Descubra o que seus gargalos e em seguida, decidir como corrigi-los.

2) todas as recomendações para uma boa plataforma cruzada de janelas kit que caberia para o cenário descrito acima?

Eu estaria olhando para mono com certeza.Esse é realmente o melhor que você pode fazer se você está indo com C#.Ele é muito bonito tanto mono ou outro reescrever em outro idioma quando/se você mudar para o Linux.

Outras dicas

1) otimização Prematura é o mal.Implementar o seu "caro" em C# e ver se você precisa refatorá-lo.Ou, configurar, pelo menos, um teste que irá permitir que você para determinar isso.

2) Ai.Cross platform INTERFACE do usuário.Eu não iria colocar-se com o "pode" coisas.Prego o doninhas para baixo;como você pode possivelmente fazer decisões de design sem saber o que você está criando?Se você for com um puro .NET implementação, eles vão reclamar se você tem (no mínimo) refatorá-lo para trabalhar em Mono?Se você criar em Java, eles vão ser incomodados que parece feio como o diabo, e os usuários se queixam de que eles não podem encontrar o seu .arquivo exe entre todos aqueles .frascos?

1) Não necessariamente.Eu acho que seria mais correto dizer que é provável que vale a pena escrever o seu back-end de código em C++, independentemente das implicações de desempenho.Mesmo que você não pode amarrar seu superior-ups para baixo na plataforma switch, seria prudente que você faça os preparativos para essa eventualidade, uma vez que a gestão de tipos tendem a mudar a sua mente um monte sem uma boa razão (ou aviso);mesmo se eles decidirem não mudar agora, isso não significa que eles não decidir mudar de seis meses a partir de agora.Escrever sua lógica em C++ agora, sabendo que é uma possibilidade, apesar de difícil, pode tornar sua vida muito mais fácil posteriormente.

2) Não realmente.Não há "soluções" como wxWindows e GTK#, mas muitas vezes eles são de buggy, ou de difícil começar a trabalhar corretamente, ou falta-lhes algo importante em uma ou outra plataforma.Eles também geralmente trancá-lo em um menor-denominador-comum de INTERFACE do usuário (ou seja, em geral os controles funcionam bem, mas você pode esquecer de sempre fazer algo de interessante -- WPF, por exemplo-com ele).Interfaces de usuário são fáceis de escrever, então eu acho que se você escrever a sua lógica em algo que é portátil, ele deve ser uma questão trivial para derrubá-se de um conjunto específico de plataforma UIs.

Para a primeira pergunta, é realmente difícil dizer se faria sentido, como seria, provavelmente depender de que tipo de desempenho que você precisa para estar recebendo.Eu, pessoalmente, não vi todo o sistema, lentidão, devido à interface de usuário corretamente projetado GUIs usando WinForms, então eu não vejo por que ele iria deve causar quaisquer problemas, e com toda a probabilidade, seria tornar a sua vida mais fácil no que diz respeito à interface de usuário.

Quanto à sua segunda pergunta, se você estiver indo para mover-se para outra plataforma em algum momento - você quer dar uma olhada nas bibliotecas que têm sido implementadas pelo Mono (http://www.mono-project.com/Main_Page), este também deve cobrir a maior parte de suas necessidades no que diz respeito à plataforma cruzada de janelas como ele suporta WinForms e GTK#.

Não, não faz sentido fazer o "caro" em C/C++.O potencial (e, provavelmente, menor) melhorias de desempenho nunca, nunca superam a sua produtividade, sendo um miserável, doente piada quando comparado com o C#.Realmente.Não é nem perto.

Leia este (e todos os posts com referência no):http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

Você pode querer olhar para usar Mono.Esta é uma versão de código aberto .NET, que é executado em muitas plateforms...Linux,Mac, Solaris, Windows, etc.

Agora sobre a codificação de seu caro em C/C++.Aqui está um artigo que faz um bom trabalho explicando as diferenças entre C/C++ & C# desempenho.

E, novamente, deixe-me enfatizar, o C++ coisas é veerrrryyyy caro.Faria sentido fazer o que eu mencionei acima?(.NET formas de esconder pesado em C++)

Como mencionado antes, eu, pessoalmente, não tenho notado qualquer sistema de grande lentidão devido a WinForms em aplicações escritas em ambos os VB.NET e C#.No entanto, se o aplicativo é realmente o desempenho intensivo, em seguida, você pode notar um ligeiro abrandar, se você escreveu tudo em C# devido a ser cumprido no CIL (http://www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/timestable-demo/).Como tal, a escrita GUI em uma linguagem como o C# vai provavelmente fazer com que parte do desenvolvimento de um pouco mais fácil que daria mais tempo para trabalhar em partes críticas do código.A única catch-22 é aqui poderá notar alguma lentidão devido ao chamadas para o código C/C++ a partir de código C#;no entanto, esta é provável muito improvável.

1) faz sentido fazer uma GUI em winforms, mas as coisas caras nativo não gerido e C/C++ ?

Provavelmente não.A menos que você está se comunicando com um monte de outras espécies, C dlls ou assim por diante, C# é provavelmente entre 5% mais 5% mais rápido de C++ (std::string realmente mata você, se você está usando-o)

2) todas as recomendações para uma boa plataforma cruzada de janelas kit que caberia para o cenário descrito acima?

Se apenas algumas formas simples com botões, mono irá provavelmente ser capaz de executá-los sem modificações.É apoio .NET WinForms é muito bom esses dias.É, no entanto, bunda feia :-)

Eu poderia ser mal entendido o problema, mas , se é um sistema de monitoramento de rede, por que não foi escrito como uma "dedicado" de serviço do Windows?

VB.NET não deve ser muito mais lento do que o C#.Eu não tenho 100% de certeza se há grandes diferenças na gerados IL-código, mas a única vantagem (e razão justificável para reescrevê-lo em C#) eu poderia pensar (exceto que o C# tem um agradável sintaxe e algumas outras coisas) é o uso de inseguro bloco de código que pode acelerar as coisas um pouco.

O c/c++ coisas pode acabar sendo uma boa idéia, mas agora YAGNI.Mesmo com o Linux coisas.Ignorá-lo, você ain't gonna need it até que você precisar.Mantê-lo simples.Teste de unidade o inferno fora dele, como você diz.Obter o código de trabalho e evoluir o design de lá.

Eu tinha dilema semelhante algum tempo atrás, enquanto tenta descobrir uma melhor maneira de desenvolver um PC baseado em H/W ferramenta de Teste (o que, obviamente, significa "com opções de INTERFACE de usuário") que interage com um hardware embarcado (via interface PCMCIA).

O gargalo era a de que o teste deve ser executado em desvio máximo de 10ms do pretendido tempo especificado pelo testador.

E. g:Se o testador cria a seguinte seqüência de teste:

o atraso mencionado no passo 2 não deve ser > 60ms.

Eu escolhi o aplicativo de C++ WIN32, como o meu back-end e VC++ 2005 Winform (.NET plataforma) para desenvolvimento de INTERFACE de utilizador.Informações detalhadas sobre como interface desses dois está disponível em msdn
Eu segregado o sistema como esse:
No VC++ .NET:

Em C++ WIN32:

Todo o sistema está ativo e em execução.Parece ser bastante estável.(Sem o desvio de tempo mencionado acima).
Note que, o teste de PC usamos é somente para o H/W finalidade de Teste (ele tinha acabado de INTERFACE do usuário em execução, sem atualizações automáticas, verificação de vírus e etc..etc..).

gtk-sharp é um muito bom de plataforma cruzada toolkit.

Gtk# é uma Interface Gráfica do Usuário kit de ferramentas para mono e .Líquida.O projeto vincula o gtk+ toolkit e um sortido de bibliotecas GNOME, permitindo totalmente nativa gráfica Gnome desenvolvimento de aplicações usando o Mono e .Líquido de desenvolvimento de frameworks.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow