문제

저는 기본적으로 네트워킹 통계를 모니터링하고 반환하는 성능이 중요한 VB.NET 앱인 일련의 응용 프로그램을 업데이트하는 임무를 맡았습니다.요구 사항은 세 가지뿐입니다. C#으로 변환해서 빠르게, 안정적으로 만들어 보세요.

한 가지 주의할 점은 우리가 "5월" .NET 플랫폼에서 Linux로 마이그레이션 "곧"

앞으로 이 앱들을 관리할 책임이 있으니 이 일을 제대로 하고 싶습니다.나는 이 나쁜 놈을 제대로 단위 테스트할 수 있도록 MVP 패턴에 따라 이러한 앱을 리팩터링하기로 결정했습니다.하지만 MVP를 사용하고 있었기 때문에 GUI는 .NET 형식이나 Qt 등을 사용하여 수행하는 동안 계산 비용이 많이 드는 작업을 네이티브 C/C++ 코드에서 수행할 수도 있다고 생각했습니다.

질문:

  1. winforms에서는 GUI를 수행하지만 관리되지 않는 네이티브 C/C++에서는 비용이 많이 드는 작업을 수행하는 것이 합리적입니까?

  2. 위에서 설명한 시나리오에 적합한 우수한 크로스 플랫폼 윈도우잉 키트에 대한 권장 사항이 있습니까?

도움이 되었습니까?

해결책

우선 시간을 투자해 몇 가지를 시도해 보겠습니다. VB.NET에서 C#으로 변환기.기본적으로 구문을 이식하는 것이므로 꼭 필요한 경우가 아니라면 직접 수행할 이유가 없습니다.물론 변환기에서 나오는 내용을 정리해야 할 수도 있지만 직접 변환하는 것보다 훨씬 낫습니다.

이제 귀하의 질문은 다음과 같습니다.

1) winforms에서는 GUI를 수행하지만 관리되지 않는 기본 C/C++에서는 비용이 많이 드는 작업을 수행하는 것이 합리적입니까?

아직 아님.변환이 완료될 때까지 기다린 다음 실제로 시간을 보내고 있는 위치를 알아보세요.필요하다는 것을 알기 전까지는 C/C++와 C#을 혼합할 이유가 없습니다.안전하지 않은 C#을 사용하는 것만으로도 충분하다는 것을 알 수 있습니다.그것조차도 불필요할 수 있다.알고리즘을 최적화해야 할 수도 있습니다.병목 현상이 무엇인지 알아보고 그 다음에 문제를 해결하는 방법을 결정합니다.

2) 위에서 설명한 시나리오에 적합한 우수한 크로스 플랫폼 윈도우잉 키트에 대한 권장 사항이 있습니까?

나는 조사하고있을 것입니다 단핵증 확실히.이는 C#을 사용하는 경우 할 수 있는 최선의 방법입니다.Linux로 이동할 때 모노 또는 다른 언어로 다시 작성하는 것과 거의 같습니다.

다른 팁

1) 조기 최적화는 악입니다.C#에서 "값비싼 작업"을 구현하고 리팩터링이 필요한지 확인하세요.아니면 최소한 이를 확인할 수 있는 테스트를 설정하세요.

2) 요치.크로스 플랫폼 UI.나는 "5월"이라는 말을 참지 않을 것입니다.족제비를 못 박으십시오.자신이 무엇을 디자인하고 있는지도 모르고 어떻게 디자인 결정을 내릴 수 있습니까?순수 .NET 구현을 사용하는 경우 Mono에서 작동하도록 (최소한) 리팩토링해야 하면 불만을 표시합니까?Java로 생성하면 보기 흉해 보여 짜증이 나고 사용자는 모든 .jar 중에서 .exe 파일을 찾을 수 없다고 불평할까요?

1) 꼭 그렇지는 않습니다.성능에 미치는 영향에 관계없이 백엔드 코드를 C++로 작성하는 것이 아마도 가치가 있다고 말하는 것이 더 정확할 것이라고 생각합니다.플랫폼 스위치에 상급자를 묶을 수는 없지만 만일의 경우에 대비하는 것이 현명할 것입니다. 관리 유형은 합당한 이유(또는 경고) 없이 마음을 많이 바꾸는 경향이 있기 때문입니다.지금 전환하지 않기로 결정했다고 해서 지금부터 6개월 후에 전환하기로 결정하지 않는다는 의미는 아닙니다.지금 C++로 논리를 작성하면 가능성이 있다는 사실을 알고 있으면 비록 더 어렵지만 나중에 생활이 훨씬 더 쉬워질 수 있습니다.

2) 그렇지 않습니다.wxWindows 및 GTK#과 같은 "솔루션"이 있지만 종종 버그가 있거나 제대로 작동하기 어렵거나 특정 플랫폼에서 중요한 것이 부족합니다.또한 일반적으로 최소 공통 분모 UI에 갇히게 됩니다. 즉, 일반 컨트롤은 잘 작동하지만 이를 사용하여 WPF와 같은 흥미로운 작업을 수행하는 것을 잊어버릴 수 있습니다.UI는 작성하기 쉽기 때문에 이식 가능한 것으로 로직을 작성하는 경우 여러 플랫폼별 UI를 하나로 묶는 것은 사소한 문제일 것이라고 생각합니다.

첫 번째 질문의 경우, 어떤 종류의 성능을 얻어야 하는지에 따라 달라질 수 있으므로 말이 되는지 말하기가 정말 어렵습니다.저는 개인적으로 WinForms를 사용하여 적절하게 설계된 GUI에서 GUI로 인해 시스템 전체가 느려지는 것을 본 적이 없습니다. 따라서 이것이 왜 문제를 일으키는지 알 수 없으며, 아마도 GUI와 관련하여 여러분의 삶을 더 쉽게 만들어 줄 것입니다. .

두 번째 질문에 관해서는, 어느 시점에 다른 플랫폼으로 이동할 예정이라면 Mono(http://www.mono-project.com/Main_Page), 이는 WinForms 및 GTK#을 지원하므로 크로스 플랫폼 창과 관련된 대부분의 요구 사항도 충족해야 합니다.

아니요, C/C++에서 "값비싼 작업"을 수행하는 것은 의미가 없습니다.C#과 비교할 때 잠재적인(그리고 대부분 사소한) 성능 향상은 생산성이 비참하고 역겨운 농담보다 결코 중요하지 않습니다.정말.가깝지도 않아요.

다음 내용(및 여기에 참조된 모든 게시물)을 읽어보세요.http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

당신은 사용을 조사하고 싶을 수도 있습니다 단핵증.이는 Linux, Mac, Solaris, Windows 등 다양한 플랫폼에서 실행되는 .NET의 오픈 소스 버전입니다.

이제 비용이 많이 드는 작업을 C/C++로 코딩하는 방법에 대해 알아보겠습니다.다음은 매우 좋은 일을하는 기사가 있습니다. C/C++ 및 C# 성능.

그리고 다시 한 번 강조하지만, C++ 관련 작업은 매우 비쌉니다.위에서 언급한 대로 수행하는 것이 합리적일까요?(무거운 C++를 숨기는 .NET 형식)

앞서 언급했듯이 저는 개인적으로 VB.NET과 C#으로 작성된 응용 프로그램에서 WinForms로 인해 시스템 전체가 느려지는 것을 발견하지 못했습니다.그러나 응용 프로그램이 실제로 성능 집약적이라면 CIL(http://www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/timestable-demo/).따라서 C#과 같은 언어로 GUI를 작성하면 개발 부분이 좀 더 쉬워지고 코드의 중요한 부분을 작업하는 데 더 많은 시간을 할애할 수 있습니다.여기서 유일한 문제는 C# 코드에서 C/C++ 코드 호출로 인해 약간의 속도 저하가 발생할 수 있다는 것입니다.그러나 이것은 가능성이 거의 없습니다.

1) winforms에서는 GUI를 수행하지만 관리되지 않는 기본 C/C++에서는 비용이 많이 드는 작업을 수행하는 것이 합리적입니까?

아마도 그렇지 않을 것입니다.다른 많은 기본 C dll 등과 통신하지 않는 한 C#은 5%에서 5% 정도 느릴 수 있습니다. 더 빠르게 C++보다 (std::string을 사용하면 정말 죽습니다)

2) 위에서 설명한 시나리오에 적합한 우수한 크로스 플랫폼 윈도우잉 키트에 대한 권장 사항이 있습니까?

버튼이 있는 단순한 양식이라면 모노는 수정하지 않고 실행할 수 있을 것입니다..NET WinForms에 대한 지원은 요즘 꽤 좋습니다.그러나 그것은 추악합니다 :-)

내가 문제를 오해하고 있는 것일 수도 있다, 그런데 네트워크 모니터링 시스템이라면 왜 "전용" Windows 서비스로 작성되지 않습니까?

VB.NET은 C#보다 훨씬 느려서는 안 됩니다.생성된 IL 코드에 큰 차이가 있는지 100% 확신할 수는 없지만 제가 생각할 수 있는 유일한 이점(그리고 이를 C#으로 다시 작성하는 정당한 이유)은 (C#이 더 멋진 구문과 다른 장점을 가지고 있다는 점을 제외하고) ) 작업 속도를 약간 높일 수 있는 안전하지 않은 코드 블록을 사용하는 것입니다.

c/C++ 작업은 결국 좋은 생각이 될 수도 있지만 지금은 YAGNI입니다.Linux와 동일합니다.무시해, 넌 그럴 필요 없을 거야 필요할 때까지.보관해라 단순한.당신이 말한 대로, 단위 테스트를 꼭 해보세요.코드를 작동시키고 디자인을 발전시키다 거기에서.

임베디드 하드웨어(PCMCIA 인터페이스를 통해)와 상호 작용하는 PC 기반 H/W 테스트 도구(분명히 "UI 옵션 포함"을 의미함)를 개발하는 가장 좋은 방법을 찾으려고 노력하면서 비슷한 딜레마에 빠졌습니다.

병목 현상은 테스트가 테스터가 지정한 의도된 시간에서 최대 10ms의 편차로 실행되어야 한다는 것입니다.

예:테스터가 다음 테스트 시퀀스를 생성하는 경우:

    1.원격으로 H/W 활성화
    2.50ms 지연을 기다립니다.
    삼.H/W 정보를 읽어보세요.

2단계에서 언급한 지연은 60ms를 초과하면 안 됩니다.


저는 백엔드로 C++ WIN32 애플리케이션을 선택했고 UI 개발에는 VC++ 2005 Winform(.NET 플랫폼)을 선택했습니다.이 두 가지를 인터페이스하는 방법에 대한 자세한 내용은 다음에서 확인할 수 있습니다. msdn
나는 다음과 같이 시스템을 분리했습니다.
VC++ .NET에서:

    1.H/W에 대한 전체 정보를 갖고(백엔드 애플리케이션을 통해 읽음) 필요에 따라 H/W를 제어하기 위한 UI입니다.(버튼, 콤보 상자 등..등..)
    2.위의 예에서 언급한 대로 시간이 중요한 테스트 시퀀스를 실행하는 UI입니다.
    삼.이러한 정보를 수집하고 시간 선형 형식(즉, 수행해야 하는 단계의 정확한 순서)으로 스트림(파일 스트림)을 구축합니다.
    4.WIN32 백엔드 애플리케이션을 사용한 트리거링 및 핸드셰이킹 메커니즘(표준 입력 및 표준 출력을 리디렉션함)공통 리소스는 파일 스트림입니다.

C++ WIN32의 경우:

    1.입력 파일 스트림 해석.
    2.H/W와의 상호작용.
    삼.H/W에서 정보를 수집하여 출력 파일 스트림에 넣습니다.
    4.UI에 테스트 완료 표시(리디렉션된 표준 출력을 통해)

전체 시스템이 가동되어 실행 중입니다.꽤 안정적인 것 같습니다.(위에서 언급한 타이밍 편차 없이).
우리가 사용하는 테스트 PC는 H/W 테스트 목적으로만 사용됩니다(자동 업데이트, 바이러스 검사 등은 없이 UI만 실행 중이었습니다.)등..).

GTK-샤프 꽤 좋은 크로스 플랫폼 툴킷입니다.

Gtk#은 모노 및 .Net용 그래픽 사용자 인터페이스 툴킷입니다.이 프로젝트는 gtk+ 툴킷과 다양한 GNOME 라이브러리를 결합하여 Mono 및 .Net 개발 프레임워크를 사용하여 완전한 기본 그래픽 Gnome 애플리케이션 개발을 가능하게 합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top