일반적으로 아무도 유형의 전체 값에 대한 배열을 만들고 지속적인 액세스 권한을 얻으려고 애쓰지 않습니다. (스위치는 정수 유형에서만 작동합니다)
설명하는 경우 enum을 도입하는 것이 더 편리합니다.
유형의 전체 크기에 대해? 너 뭐야! 이 경우 16GB의 메모리가 필요합니다(int 유형 배열의 경우). 그리고 전체의 요점은 무엇입니까? 가장 큰 값과 가장 작은 값의 차이를 계산하는 것으로 충분합니다. 그러나 이것은 여전히 논쟁의 여지가 있는 옵션입니다. 큰 값의 경우 먼저 사용자가 프로그램에 제공할 준비가 된 메모리 양에 동의해야 합니다. 따라서 이것은 작은 키 값에만 적합합니다(더 정확하게는 최대값과 최소값 사이의 작은 차이). 그래서 바이너리 검색 만 있습니다.
약속한 대로 한 프로젝트를 프로파일링한 결과를 게시합니다. (저를 비난하지 마십시오. 그러나 코드는 일반 대중을 위한 것이 아니기 때문에 일부 기능은 은폐되었습니다.)
우선 이것은 소스 데이터의 강력한 변환이 포함된 실제 OOP 프로젝트라고 말할 것입니다. OOP를 사용한다는 아이디어는 절대적입니다. 예를 들어, 전역 변수, 배열, 클래스 외부의 함수는 전혀 사용하지 않습니다. 왜냐하면 충분히 OO가 아니기 때문입니다. 운영을 위해서는 전체 기간 동안 이루어진 주문 및 거래 내역이 필요합니다. 6014개 거래 및 6599개 주문을 구문 분석하는 데 트랜잭션당 3.1초 또는 0.25밀리초가 소요되며 모든 거래, 주문 및 위치를 배포하는 데 약 13MB의 RAM이 필요하거나 트랜잭션당 평균 1킬로바이트가 필요합니다. - 이것은 OOP 응용 프로그램에 대한 매우 좋은 결과라고 생각합니다.
2014.07.07 12:44:33.464 TestMA (AUDCAD,H1) 시작합니다. 3.104초 동안 완료된 이력 거래(6014) 및 주문(6599)의 구문 분석. 13MB RAM이 사용되었습니다.
그러나 응용 프로그램을 초기화할 때 소요된 시간 구조를 살펴보겠습니다.
대부분의 시간이 AddNewDeal 함수를 호출하는 데 소비되는 것을 알 수 있습니다. 이것은 복합 함수이며 실제 작업은 RecalcValues(57%)에 위임됩니다. 이는 차례로 HistoryOrderGetInteger 유형의 시스템 기능으로 구성됩니다.
이러한 함수에 대한 호출 시간은 거의 균일합니다.
이것이 전체 함수 파이프라인의 끝이라는 점에 유의하십시오. 이러한 계산에 도달하기 전에 12가지 이상의 중간 OOP 방법을 거쳐야 하며 그 중 일부는 가상이기도 합니다. 그러나 실행 시간은 무시할 수 있으며 프로파일러에서는 목록의 후반부에 들어갑니다.
애플리케이션이 100% OOP이기 때문에 시간이 중요한 코드 섹션을 추적하는 것이 매우 쉽고 성능을 매우 효율적으로 개선할 수 있는 새로운 방법을 찾을 수 있습니다. 나머지(43%)가 80-90% CArray.Resize() 호출이라는 것을 이미 알고 있습니다. 코드가 최적화되지 않고 배열의 크기가 필요 이상으로 자주 조정되는 곳이 몇 군데 있습니다. 이러한 OOP 모듈을 쉽게 다시 작성할 수 있고 성능을 25%-30% 향상시킬 수 있습니다. OOP가 없으면 각 기능이 잠재적으로 무한한 수의 관계에 참여하고 이러한 기능에 대한 변경 결과를 계산하는 것이 훨씬 더 어려워지기 때문에 이 작업을 수행하기가 더 어렵습니다.
그 결과 복잡한 OOP 프로젝트라도 기본 시스템 기능의 성능 한계로 축소될 수 있음을 알 수 있다. 그러나 OOP가 없으면 이러한 성능을 달성하기가 더 어려울 것입니다. 너무 많은 기능이 있어서 조만간 실수를 하게 될 것입니다. 추가 호출을 하거나 최적화되지 않은 대응을 하거나 너무 복잡하고 성가신 구현을 하게 될 것입니다.
약속한 대로 한 프로젝트를 프로파일링한 결과를 게시합니다. (저를 비난하지 마십시오. 그러나 코드는 일반 대중을 위한 것이 아니기 때문에 일부 기능은 은폐되었습니다.)
...
왜 그게 다야? 기능 코드를 제공하지 않았습니다(일부 찢어진 부분 제외). 그래서 무엇을 논의할 것인가? 여기서 주제는 특히 OOP와 절차적 프로그래밍의 성능을 비교하는 것에 관한 것입니다. 그리고 당신의 비밀 기능이 어떤 종류의 작업을 수행하고, 어딘가에 무언가를 위임하고, 시간을 보내고, 당신이 이 모든 것을 능숙하게 관리한다는 사실 - 우리는 물론 당신에게 매우 행복하지만 우리가 만약 코드가 표시되지 않습니다.
왜 그게 다야? 기능 코드를 제공하지 않았습니다(일부 찢어진 부분 제외). 그래서 무엇을 논의할 것인가? 여기서 주제는 특히 OOP와 절차적 프로그래밍의 성능을 비교하는 것에 관한 것입니다. 그리고 당신의 비밀 기능이 어떤 종류의 작업을 수행하고, 어딘가에 무언가를 위임하고, 시간을 보내고, 당신이 이 모든 것을 능숙하게 관리한다는 사실 - 우리는 물론 당신에게 매우 행복하지만 우리가 만약 코드가 표시되지 않습니다.
그는 실제 프로젝트 에서 직접 호출이나 가상 호출이 영향을 미치지 않는다는 것을 보여주었습니다.
실제 OOP 프로젝트를 프로파일링하는 예를 사용 하여 한계 내에서의 성능이 시스템 함수 호출의 성능으로 이어지는 경향이 있음을 보여줍니다.
대부분의 비용은 MQL 프로그램의 거의 모든 시간을 소비하는 시스템 기능 호출에 소비됩니다. 호출 설정 비용은 페이로드에 비해 무시할 수 있습니다.
여기에서 내가 알기로는 이진 검색을 통해 인덱스가 결정됩니까?
아니요, 어레이에서와 같이 직접 액세스합니다.
__________
음, 흥분한 걸지도 몰라, 지금 당장 생각해볼게.
일반적으로 아무도 유형의 전체 값에 대한 배열을 만들고 지속적인 액세스 권한을 얻으려고 애쓰지 않습니다. (스위치는 정수 유형에서만 작동합니다)
설명하는 경우 enum을 도입하는 것이 더 편리합니다.
아니요, 어레이에서와 같이 직접 액세스합니다.
__________
음, 흥분한 걸지도 몰라, 지금 당장 생각해볼게.
일반적으로 아무도 유형의 전체 값에 대한 배열을 만들고 지속적인 액세스 권한을 얻으려고 애쓰지 않습니다. (스위치는 정수 유형에서만 작동합니다)
설명하는 경우 enum을 도입하는 것이 더 편리합니다.
유형의 전체 크기에 대해? 너 뭐야! 이 경우 16GB의 메모리가 필요합니다(int 유형 배열의 경우). 그리고 전체의 요점은 무엇입니까? 가장 큰 값과 가장 작은 값의 차이를 계산하는 것으로 충분합니다. 그러나 이것은 여전히 논쟁의 여지가 있는 옵션입니다. 큰 값의 경우 먼저 사용자가 프로그램에 제공할 준비가 된 메모리 양에 동의해야 합니다. 따라서 이것은 작은 키 값에만 적합합니다(더 정확하게는 최대값과 최소값 사이의 작은 차이). 그래서 바이너리 검색 만 있습니다.
따라서 이진 검색만 있습니다.
아니요, 꼭 필요한 것은 아닙니다. 간단히 말해서, 숫자를 열거형에 매핑해야 하는 경우 이진 검색 이 필요합니다. 열거형으로 작업하고 열거형을 숫자에 매핑하는 데 충분하면 상수입니다.
기억에 관해서는 이해합니다)) 그래서 흥분했다고 썼습니다. 손대지 않고는 아직 길다.
질문을 위한 장소는 항상 있습니다 - 왜? 스프레드 차트를 온라인과 테스터에서 비교하십시오. 테스터는 현실과 무관합니다...
좀 더 자세한 설명(증거)이 이미 어딘가에서 나왔나요?
여기에서는 귀하의 진술을 증거로 뒷받침하는 것이 일반적입니다. 그렇지 않으면 그들은 심지어 그것을 볼 것입니다. ;)
얘들아, 스위치 문서를 피워 라. 좋은 스위치는 성능이 선택 항목 수와 무관한 전환 전환입니다. 옵션 1, 100 또는 1000 - 전환 속도는 일정합니다.
질문을 위한 장소는 항상 있습니다 - 왜 ? 스프레드 차트를 온라인과 테스터에서 비교하십시오. 테스터는 현실과 무관합니다...
증거는 반대편에 있을 것입니다. 또는 다시 말하지만.
대체로 사실만이 관심 대상입니다.
OOP가 더 느리다는 것을 이미 알고 있지만 매우 구체적인 편의를 제공합니다.
약속한 대로 한 프로젝트를 프로파일링한 결과를 게시합니다. (저를 비난하지 마십시오. 그러나 코드는 일반 대중을 위한 것이 아니기 때문에 일부 기능은 은폐되었습니다.)
우선 이것은 소스 데이터의 강력한 변환이 포함된 실제 OOP 프로젝트라고 말할 것입니다. OOP를 사용한다는 아이디어는 절대적입니다. 예를 들어, 전역 변수, 배열, 클래스 외부의 함수는 전혀 사용하지 않습니다. 왜냐하면 충분히 OO가 아니기 때문입니다. 운영을 위해서는 전체 기간 동안 이루어진 주문 및 거래 내역이 필요합니다. 6014개 거래 및 6599개 주문을 구문 분석하는 데 트랜잭션당 3.1초 또는 0.25밀리초가 소요되며 모든 거래, 주문 및 위치를 배포하는 데 약 13MB의 RAM이 필요하거나 트랜잭션당 평균 1킬로바이트가 필요합니다. - 이것은 OOP 응용 프로그램에 대한 매우 좋은 결과라고 생각합니다.
그러나 응용 프로그램을 초기화할 때 소요된 시간 구조를 살펴보겠습니다.
대부분의 시간이 AddNewDeal 함수를 호출하는 데 소비되는 것을 알 수 있습니다. 이것은 복합 함수이며 실제 작업은 RecalcValues(57%)에 위임됩니다. 이는 차례로 HistoryOrderGetInteger 유형의 시스템 기능으로 구성됩니다.
이러한 함수에 대한 호출 시간은 거의 균일합니다.
이것이 전체 함수 파이프라인의 끝이라는 점에 유의하십시오. 이러한 계산에 도달하기 전에 12가지 이상의 중간 OOP 방법을 거쳐야 하며 그 중 일부는 가상이기도 합니다. 그러나 실행 시간은 무시할 수 있으며 프로파일러에서는 목록의 후반부에 들어갑니다.
애플리케이션이 100% OOP이기 때문에 시간이 중요한 코드 섹션을 추적하는 것이 매우 쉽고 성능을 매우 효율적으로 개선할 수 있는 새로운 방법을 찾을 수 있습니다. 나머지(43%)가 80-90% CArray.Resize() 호출이라는 것을 이미 알고 있습니다. 코드가 최적화되지 않고 배열의 크기가 필요 이상으로 자주 조정되는 곳이 몇 군데 있습니다. 이러한 OOP 모듈을 쉽게 다시 작성할 수 있고 성능을 25%-30% 향상시킬 수 있습니다. OOP가 없으면 각 기능이 잠재적으로 무한한 수의 관계에 참여하고 이러한 기능에 대한 변경 결과를 계산하는 것이 훨씬 더 어려워지기 때문에 이 작업을 수행하기가 더 어렵습니다.
그 결과 복잡한 OOP 프로젝트라도 기본 시스템 기능의 성능 한계로 축소될 수 있음을 알 수 있다. 그러나 OOP가 없으면 이러한 성능을 달성하기가 더 어려울 것입니다. 너무 많은 기능이 있어서 조만간 실수를 하게 될 것입니다. 추가 호출을 하거나 최적화되지 않은 대응을 하거나 너무 복잡하고 성가신 구현을 하게 될 것입니다.
질문을 위한 장소는 항상 있습니다 - 왜? 스프레드 차트를 온라인과 테스터에서 비교하십시오. 테스터는 현실과 무관합니다...
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
반짝임과 불행 OOP
톨64 , 2014.07.07 09:12
관심을 끌기 위해. 새로운 주제를 열고 질문을 더 자세히 다루십시오. 실제 생활에서 방법과 테스터에서 방법을 보여줍니다. 이 문제에 대한 해결책을 제안하십시오. 그렇지 않으면 모든 것이 "기회와 옵션이 없음"으로 남습니다. )++++
to dimeon - 주제를 열면 왜 불가능한지, 왜 필요한지 많은 주장을 배우게 됩니다.
약속한 대로 한 프로젝트를 프로파일링한 결과를 게시합니다. (저를 비난하지 마십시오. 그러나 코드는 일반 대중을 위한 것이 아니기 때문에 일부 기능은 은폐되었습니다.)
...
왜 그게 다야? 기능 코드를 제공하지 않았습니다(일부 찢어진 부분 제외). 그래서 무엇을 논의할 것인가? 여기서 주제는 특히 OOP와 절차적 프로그래밍의 성능을 비교하는 것에 관한 것입니다. 그리고 당신의 비밀 기능이 어떤 종류의 작업을 수행하고, 어딘가에 무언가를 위임하고, 시간을 보내고, 당신이 이 모든 것을 능숙하게 관리한다는 사실 - 우리는 물론 당신에게 매우 행복하지만 우리가 만약 코드가 표시되지 않습니다.
왜 그게 다야? 기능 코드를 제공하지 않았습니다(일부 찢어진 부분 제외). 그래서 무엇을 논의할 것인가? 여기서 주제는 특히 OOP와 절차적 프로그래밍의 성능을 비교하는 것에 관한 것입니다. 그리고 당신의 비밀 기능이 어떤 종류의 작업을 수행하고, 어딘가에 무언가를 위임하고, 시간을 보내고, 당신이 이 모든 것을 능숙하게 관리한다는 사실 - 우리는 물론 당신에게 매우 행복하지만 우리가 만약 코드가 표시되지 않습니다.
그는 실제 프로젝트 에서 직접 호출이나 가상 호출이 영향을 미치지 않는다는 것을 보여주었습니다.
실제 OOP 프로젝트를 프로파일링하는 예를 사용 하여 한계 내에서의 성능이 시스템 함수 호출의 성능으로 이어지는 경향이 있음을 보여줍니다.
대부분의 비용은 MQL 프로그램의 거의 모든 시간을 소비하는 시스템 기능 호출에 소비됩니다. 호출 설정 비용은 페이로드에 비해 무시할 수 있습니다.