우리 회사에서는 한 응용 프로그램에서 다른 응용 프로그램으로 전환해야하는지 평가하고 있으며 일부 성능 관련 질문 (말도 안되는 ...)이 있습니다. 일부 COM 관련 기사를 읽었으며 가장 명확한 사항은 그것은 언어에 독립적이지만 성능은 어떻습니까?COM 응용 프로그램 comunication 성능
우리는 제 3 자 전기 그리드 솔버 트로프 및 C# API를 사용합니다. 우리는 그것에 만족하지 않습니다. (API를 COM과 동일하게 사용합니까?)
경쟁자는 모두 COM 통신을 사용합니다.
우리가 사용하는 프로그램은 확률 적 시뮬레이션 프레임 워크가 될 것이므로 COM 통신을 사용할 가치가 있습니까? 매우 느린가?
나는 이것에 전혀 경험이 없기 때문에 나는 약간의 빛을 원한다. COM 통신을 할 때
일반적으로 구성 요소 공급 업체는 COM 인터페이스를 선호합니다. 그 이유는 더 많은 런타임 환경에서 제품을 사용할 수 있기 때문입니다. C++, Delphi 또는 스크립팅 언어와 같은 언어를 포함합니다. 그리고 C#, .NET 프레임 워크는 COM interop에 대한 지원이 매우 뛰어났습니다. 은 기본 C# 인터페이스처럼처럼 보입니다. COM을 아직 사용하지 않고 그냥 모르는 지 확인하십시오. 배포 지침에서 힌트를 얻을 수 있습니다. 일반적으로 COM 구성 요소에는 매니페스트 나 설치 관리자가 필요합니다.
COM은 종종 오랜 시간, 10 년 이상 된 제품에 대한 광고 인터페이스입니다. 일반적인 "그리드 솔버 (grid solver)"유형의 제품 일 가능성이 있습니다. 10 년 동안 새로운 종과 호각이 추가되지 않아 안정적인 제품입니다. 이것은주의해야 할 사항이며, 일반적으로 공급 업체가 프로그래머가 제품을 더 이상 사용하지 않기 때문에 그러한 제품에 대한 지원을 얻는 데 어려움이 있습니다. 제품 지원에 의존하는 핵심 라이브러리를 교체 할 때 올바른 지원을받는 것이 항상 중요합니다.
perf 문제가있을 때 지원이 특히 중요합니다. 문제를 해결하기 위해 스스로 할 수있는 일이별로 없으며, 벤더와 협력하여 문제를 해결할 수 있기를 정말로 원합니다.
COM은 원본이 API 계층 오버 헤드 인 경우 perf 문제에 대한 확실한 해결책이 아닙니다. 어떤 은 일 수 있습니다. 솔버가 별도의 프로세스 인 경우 이러한 interop는 비용이 많이 듭니다. Taskmgr.exe, Processes 탭에서 쉽게 볼 수있는 것, 앱을 실행할 때 또 다른 EXE 팝업이 나타납니다.그럼에도 불구하고 COM에는 필연적으로 관리되는 코드에서 관리되지 않는 코드로 이동하는 썽크가 포함됩니다. 일반적으로 매우 빠르지 만 API 호출이 매우 세분화되어 있으면 더할 수 있습니다.
설명을 주셔서 감사합니다. 이제 조금 더 알아 보겠습니다. 아마도 이미 COM을 사용하고있을 것입니다. .. 우리는 dll을 사용하여 프로그램 기능을 호출합니다. COM인지 아닌지는 알 수 없습니다. – user721807
프로그램 구식에 대한 조언을 주셔서 감사합니다. – user721807
두 possibiities는 기본적으로 사전에
감사 : 1) 공정 중, 2) 독립 프로세스.
최대의 성능을 원한다면, 실제로는 in-process COM을 사용하십시오. 코드는 클라이언트 코드와 동일한 프로세스에서 실행되므로 직렬화 또는 "마샬링"이 필요하지 않습니다. 이 경우에는 실제로 "통신"계층이 없습니다. COM은 매우 간단한 바이너리 계약이다. 일부 미묘한는 the threading model 특히, 처리중인 COM에 대해이 있습니다 Virtual method table
주 : v 테이블의 성능에 대한 The layout of a COM object
더 많은 정보는 여기에서 찾을 수 있습니다 : 여기에 설명 된 것. 프로세스 중에도 클라이언트/호출 코드에 맞는 스레딩 모델을 선택해야합니다. 따라서이 기사의 "혼합 모델 개발"장에서 "마샬링"이 아닌 "직접 액세스"를 원합니다 (표 참조).
전반적인 COM 성능은 최고입니다. 성능이 과도한 호출, 프로세스 간 통신 왕복 등과 같은 잘못된 디자인 요소를 숨기거나 수정하는 데 충분하지만 그 의미는 아닙니다. –