대규모 애플리케이션에서 STL을 피해야합니까?

이것은 이상한 질문으로 들릴 수 있지만 부서에서 다음 상황에 문제가 있습니다.

우리는 서버 응용 프로그램을 개발 중입니다. 서버 응용 프로그램을 처리하기 위해 필요에 따라 동적으로로드하고 나중에 언로드하는 것을 고려할 때조차도 점점 커지고 있습니다. 성능 문제.

그러나 우리가 사용하는 함수는 STL 객체로 입력 및 출력 매개 변수를 전달 하고 있으며 스택 오버플로 답변에서 언급했듯이 이것은 매우 나쁜 생각입니다. (포스트에는 몇 가지 ± 솔루션과 해킹이 포함되어 있지만 모두 견고하지는 않습니다.)

분명히 우리는 입력 / 출력 매개 변수를 표준 C ++ 유형으로 바꾸고 함수 내부에서 STL 객체를 만들 수 있지만 성능 저하가 발생할 수 있습니다.

하나의 단일 PC가 더 이상 처리 할 수 ​​없을 정도로 커질 수있는 응용 프로그램 구축을 고려중인 경우 STL을 기술로 사용해서는 안된다고 결론을 내릴 수 있습니까?

이 질문에 대한 추가 배경 : 질문에 대한
오해가있는 것 같습니다. 문제는 다음과 같습니다.
응용 프로그램이 작업을 완료하기 위해 엄청난 양의 성능 (CPU, 메모리)을 사용하고 있으며이 작업을 분할하고 싶습니다. 다른 부분으로 (프로그램이 이미 여러 기능으로 분리되어 있기 때문에) 내 응용 프로그램에서 일부 DLL을 만들고 해당 DLL의 내보내기 테이블에 일부 기능을 넣는 것은 어렵지 않습니다. 다음과 같은 상황이 발생합니다.

+-----------+-----------+----
| Machine1  | Machine2  | ...
| App_Inst1 | App_Inst2 | ...
|           |           |    
| DLL1.1    | DLL2.1    | ...
| DLL1.2    | DLL2.2    | ...
| DLL1.x    | DLL2.x    | ...
+-----------+-----------+----

App_Inst1은 Machine1에 설치된 응용 프로그램의 인스턴스이고 App_Inst2는 Machine2에 설치된 동일한 응용 프로그램의 인스턴스입니다.
DLL1.x는 Machine1에 설치된 DLL이고 DLL2.x는 Machine2에 설치된 DLL입니다.
DLLx.1은 내 보낸 기능 1을 다룹니다.
DLLx.2는 내 보낸 function2를 다룹니다.

이제 Machine1에서 function1과 function2를 실행하고 싶습니다. 이것이 Machine1에 과부하가 걸리므로 App_Inst2에 메시지를 보내 해당 응용 프로그램 인스턴스가 function2를 수행하도록 요청하고 싶습니다.

function1 및 function2의 입력 / 출력 매개 변수는 STL (C ++ 표준 형식 라이브러리) 개체이며, 정기적으로 고객이 App_Inst1, App_Inst2, DLLx.y를 업데이트 할 것으로 예상 할 수 있습니다 (그러나 모두는 아니지만 고객은 Machine1을 업그레이드 할 수는 있지만 Machine2가 아니거나 응용 프로그램 만 업그레이드하지만 DLL은 업그레이드하지 않으며 그 반대도 마찬가지입니다 ...). 인터페이스 (입력 / 출력 매개 변수)가 변경되면 고객은 업그레이드를 완료해야합니다.

그러나 언급 된 StackOverflow URL에서 언급했듯이 App_Inst1 또는 DLL 중 하나의 간단한 재 컴파일로 인해 전체 시스템이 손상 될 수 있으므로이 게시물의 원래 제목이 STL (C ++ 표준 템플릿)의 사용을 거부합니다 큰 응용 프로그램의 경우 라이브러리).

이에 의해 몇 가지 질문 / 의견이 해결 되었기를 바랍니다.

이것은 냉정한 고전적인 XY 문제입니다.

당신의 진짜 문제는 성능 문제입니다. 그러나 귀하의 질문에 따르면 성능 문제가 실제로 어디에서 발생했는지에 대한 프로파일 링이나 기타 평가를 수행하지 않았다는 것이 분명합니다. 대신 코드를 DLL로 분할하면 문제를 해결할 수있는 마술 적으로 문제가 해결되기를 기대하고 있습니다.

대신 실제 문제를 해결해야합니다. 실행 파일이 여러 개인 경우 속도 저하를 일으키는 실행 파일을 확인하십시오. 당신이 그것을하고있는 동안, 실제로 잘못 처리 된 이더넷 드라이버 나 그와 비슷한 것이 아니라 모든 처리 시간이 걸리는 프로그램인지 확인하십시오. 그런 다음 코드에서 다양한 작업을 프로파일 링하십시오. 고정밀 타이머는 당신의 친구입니다. 고전적인 솔루션은 코드 덩어리에 대한 평균 및 최악의 처리 시간을 모니터링하는 것입니다.

데이터가 있으면 문제를 해결하는 방법을 찾은 다음 최적화 할 위치를 해결할 수 있습니다.

여러 물리적 시스템간에 소프트웨어를 분할해야하는 경우 시스템간에 데이터를 전달할 때 특정 형식의 직렬화 형식을 가져야합니다. 경우에 따라서는 실제로는 시스템간에 동일한 정확한 바이너리를 보낼 수 있기 때문입니다. 대부분의 직렬화 방법에는 STL 유형을 처리하는 데 아무런 문제가 없으므로 대소 문자가 아닙니다.

응용 프로그램을 공유 라이브러리 (DLL)로 분할해야하는 경우 (성능상의 이유로이를 수행하기 전에 실제로 성능 문제를 해결해야합니다) STL 객체를 전달하는 것이 문제가 될 수 있지만 반드시 그런 것은 아닙니다. 제공 한 링크에서 이미 설명했듯이 동일한 컴파일러 및 동일한 컴파일러 설정을 사용하는 경우 STL 객체 전달이 작동합니다. 사용자가 DLL을 제공하면이를 쉽게 계산하지 못할 수 있습니다. 모든 DLL을 제공하고 모든 것을 함께 컴파일하면 DLL을 신뢰할 수 있고 DLL 경계를 넘어 STL 객체를 사용하는 것이 가능해집니다. STL 관련 문제는 아니지만 객체 소유권을 전달할 때 여러 개의 서로 다른 힙을 얻지 않도록 컴파일러 설정을 계속 지켜봐야합니다.

우리는 서버 응용 프로그램을 위해 노력하고 있습니다. 서버 응용 프로그램을 다른 부분 (DLL)으로 나누고 필요할 때 동적으로로드하고 나중에 언로드하는 것을 고려할 때조차도 점점 커지고 있습니다. 성능 문제

RAM이 저렴하므로 비활성 코드가 저렴합니다. 코드로드 및 언로드 (특히 언로드)는 취약한 프로세스이며 최신 데스크탑 / 서버 하드웨어의 프로그램 성능에 큰 영향을 미치지는 않습니다.

캐시는 비싸지 만 최근에 활성화 된 코드에만 영향을 미치며 사용되지 않는 메모리에 저장된 코드에는 영향을 미치지 않습니다.

일반적으로 프로그램은 코드 크기가 아니라 데이터 크기 또는 CPU 시간으로 인해 컴퓨터보다 더 많이 사용됩니다. 코드 크기가 너무 커져 주요 문제가 발생하는 경우 처음부터 왜 그런 일이 발생하는지 살펴보고 싶을 것입니다.

그러나 우리가 사용하는 함수는 입력 및 출력 매개 변수를 STL 객체로 전달하고 있으며이 StackOverflow URL에서 언급했듯이 이것은 매우 나쁜 생각입니다.

dll과 실행 파일이 모두 동일한 컴파일러로 빌드되고 동일한 C ++ 런타임 라이브러리에 동적으로 연결되어 있으면 괜찮습니다. 응용 프로그램과 관련 dll이 단일 단위로 빌드되고 배포되면 문제가되지 않습니다.

문제가 될 수있는 곳은 다른 사람들이 라이브러리를 만들거나 별도로 업데이트 할 수있는 경우입니다.

하나의 단일 PC가 더 이상 처리 할 수 ​​없을 정도로 커질 수있는 응용 프로그램을 구축하려는 경우 STL을 기술로 사용해서는 안된다고 결론을 내릴 수 있습니까?

실제로는 아닙니다.

여러 컴퓨터에 응용 프로그램을 배포하기 시작하면 해당 컴퓨터간에 데이터를 전달하는 방법에 대해 완전히 고려해야합니다. STL 유형 이상의 기본 유형 사용 여부에 대한 세부 사항은 노이즈에서 유실 될 수 있습니다.

아니요, 결론은 다음과 같습니다. 프로그램이 여러 시스템에 분산되어 있어도 STL을 내부적으로 사용하면 모듈 간 / 프로세스 통신에서 STL을 강제로 사용할 이유가 없습니다.

사실, 내부 인터페이스와 내부 인터페이스를 비교했을 때 변경하기가 더 견고하고 어렵 기 때문에 외부 인터페이스 디자인을 시작부터 내부 구현과 분리해야한다고 주장합니다.

그 질문의 요점이 없습니다.

기본적으로 두 가지 유형의 DLL이 있습니다. 당신 자신과 다른 사람. "STL 문제"는 귀하와 이들이 동일한 컴파일러를 사용하지 않을 수 있다는 것입니다. 분명히, 그것은 당신의 DLL에 대한 문제가 아닙니다.

동일한 컴파일러 및 빌드 옵션을 사용하여 동일한 소스 트리에서 DLL을 동시에 빌드하면 정상적으로 작동합니다.

그러나 응용 프로그램을 여러 조각으로 나누는 "Windows 맛"방법은 일부는 COM 구성 요소 입니다. 이 크기는 작거나 (개별 컨트롤 또는 코덱) 크거나 (IE는 mshtml.dll에서 COM 컨트롤로 사용 가능)

필요할 때 동적으로로드하고 나중에 언로드

서버 응용 프로그램의 경우 아마도 효율성 이 끔찍할 것입니다. 오랜 시간 동안 여러 단계를 거쳐 이동하는 응용 프로그램이있을 때 실제로 실행 가능하므로 무언가 다시 필요하지 않을 때를 알 수 있습니다. 오버레이 메커니즘을 사용하는 DOS 게임을 상기시킵니다.

또한 가상 메모리 시스템이 제대로 작동하면 사용하지 않는 코드 페이지를 페이징하여 처리합니다.

하나의 PC로 더 이상 처리 할 수 ​​없을 정도로 커질 수 있습니다.

더 큰 PC를 구입하십시오.

올바른 최적화를 통해 랩톱이 hadoop 클러스터보다 성능이 우수 하다는 것을 잊지 마십시오 .

실제로 여러 시스템 이 필요한 경우 직렬화 비용이 발생하기 때문에 시스템 간의 경계에 대해 매우 신중하게 고려해야합니다. MPI와 같은 프레임 워크를 살펴보아야합니다.

우리는 서버 응용 프로그램을 개발 중입니다. 서버 응용 프로그램을 처리하기 위해 필요에 따라 동적으로로드하고 나중에 언로드하는 것을 고려할 때조차도 점점 커지고 있습니다. 성능 문제.

첫 번째 부분은 의미가 있습니다 (성능상의 이유로 응용 프로그램을 다른 컴퓨터로 분할).

두 번째 부분 (라이브러리로드 및 언로드 라이브러리)은 이해하기에 추가 노력이므로 실제로는 개선되지 않습니다.

설명하는 문제는 전용 계산 기계로 더 잘 해결되지만 동일한 (주) 응용 프로그램에서 작동하지 않아야합니다.

고전적인 솔루션은 다음과 같습니다.

[user] [front-end] [machine1] [common resources]
                   [machine2]
                   [machine3]

프런트 엔드 컴퓨터와 계산 컴퓨터 사이에로드 밸런서 및 성능 모니터링과 같은 추가 항목이있을 수 있으며 전용 컴퓨터에서 특수 처리를 유지하는 것은 캐싱 및 처리량 최적화에 좋습니다.

이것은 DLL의 추가로드 / 언로드 나 STL과 관련이 없음을 의미하지 않습니다.

즉, 필요에 따라 STL을 내부적으로 사용하고 요소간에 데이터를 직렬화하십시오 (grpc 및 프로토콜 버퍼 및 이들이 해결하는 문제 종류 참조).

이것은 당신이 제공 한 제한된 정보로, 이것은 고전적인 xy 문제처럼 보입니다 (@Graham이 말했듯이).