그리고 어떻게 "진입 신호로 좋지 않은가요 ??? 그리고 나는 바보입니다, 나는이 지표 만 사용하여 "변동성 분석"엔트리를 사용합니다 ...
지표의 본질에 대한 자신만의 특별한 이해가 있지 않나 생각합니다... 저에게 지표는 시간에 따라 가변적인 가치를 만들어낼 수 있는 객체입니다. 사실 일반 촛대 가격 차트도 지표입니다. 그러나 당신에게 그것은 다른 것입니다. 따라서 우리의 이해는 다릅니다.
사실이라면 표시기 = 무언가의 변경 사항을 보여주는 도구(장치). 이 관점에서 ATP 지표. 내 게시물에서 나는 시장에 진입하기위한 신호 제공자로서의 지표라는 단어를 의미했습니다.(나는 "영구 시장"모드에서 거래하기위한 테스트 지표 에 대해 이야기하고있었습니다). 결과적으로 테이크, 스톱 및 지원 없이 진입 및 반전 신호를 보여야 합니다. 많은 거래 시스템이 있지만 항상 시장에 있는 지표에 순전히 거래할 기회를 찾고 있었습니다. 내가 아는 한 변동성의 분석은 특정 테이크 앤 스톱으로 거래됩니다.
Я не вижу особой разницы - как я понимаю, WS (WareStore, вероятно ?) - это все тот же мой дата-провайдер.
Work Symbol 의 약자입니다. 이 개체를 자주 참조하기 때문에 의도적으로 짧은 약어를 선택했습니다.
WS 개체의 초기화에는 몇 가지 예비 단계가 있어야 한다고 생각합니다.
WS에서 이것은 기본 생성자가 현재 Symbol() 기호를 사용하는 CSymbol 개체의 인스턴스입니다. 따라서 WS는 외부에서 초기화할 필요가 없습니다. 단순히 전략 클래스와 함께 생성됩니다.
Expert Advisor에는 서로 다른 기호와 시간대가 포함된 다양한 컨테이너가 있을 수 있습니다. 데이터 제공자의 이념은 복제를 허용하지 않습니다. 실제이기 때문에 모든 시계열이 여기에 저장되고 컨테이너는 단순히 필요한 시계열을 가리킵니다.
결과적으로 전문가 클래스에서 액세스할 수 있는 하나의 메가 클래스 코어가 확보됩니다. MetaTrader 코어와 이에 액세스하는 수백 가지 기능이 있는 경우 이것이 기본 MQL과 어떻게 다릅니까?
MT4-5 자체를 데이터 공급자로 간주하고 액세스를 제공하기 위해서만 클래스를 사용하는 경우 Open 가격에 대한 귀하의 호소에 따라 하나의 값에 대해 CopyOpen() 함수를 호출해야 합니다. 나에게 불합리한.
정확히. 그러한 항소만이 데이터 표현의 통일성과 상태의 완전한 동기화를 보장합니다. 따옴표(잊을 수 있음)를 업데이트할 필요가 없으며, 중간 데이터 웨어하우스를 생성할 때 필연적으로 발생하는 추가 토글 스위치를 사용할 필요가 없습니다. 요청된 데이터와 일치하는 데이터를 데이터베이스에서 검색할 필요가 없습니다. 내 EA가 다음을 수행하는 경우:
Trade.SellLimit(WS. High [ 1 ]);
그런 다음 그는 WS.High[1]가 거래 환경이 업데이트되는 방식에 관계없이 이전 극값을 자신에게 반환할 것임을 확실히 알고 있습니다. 예, 실행할 때마다 CopyHigh 를 호출하고 단일 double 값을 복사하는 것은 비용이 많이 들지만 100% 신뢰할 수 있습니다. 래퍼 클래스는 데이터를 저장하지 않고 시스템 함수에 대한 호출에만 전달하기 때문에 저장된 데이터가 현재 환경과 일치하지 않는 상황이 발생할 수 없습니다.
또한 프로그램의 모든 변수에 대한 전체 전역 액세스 권한을 부여하는 것은 매우 비합리적이라고 생각합니다. 반대로 프로그램의 모든 위치에서 이 작업에 필요한 구조와 데이터에만 액세스할 수 있도록 노력합니다. 다른 모든 것은 사용할 수 없어야 합니다. 데이터 제공자의 이념은 이 액세스를 제어할 수 있도록 허용합니다.
Georg, 사실 당신은 이미 이 전역 액세스를 생성했습니다. 모든 사람이 요청하는 하나의 큰 슈퍼 클래스 공급자가 있습니다. 이것은 OOP 캔디 래퍼 아래에서 조립되는 하나의 큰 전역 개체 풀(지표, 시계열 등)입니다. 저것들. OOP는 데이터 공급자의 예에서 허구로 변했습니다. 형식적으로 존재하지만 현실에는 존재하지 않는다.
Georg, 사실 당신은 이미 이 전역 액세스를 생성했습니다. 모든 사람이 요청하는 하나의 큰 슈퍼 클래스 공급자가 있습니다. 이것은 OOP 캔디 래퍼 아래에서 조립되는 하나의 큰 전역 개체 풀(지표, 시계열 등)입니다. 저것들. OOP는 데이터 공급자의 예에서 허구로 변했습니다. 형식적으로 존재하지만 현실은 그렇지 않다.
아니요, 데이터 공급자에 버퍼를 배치할 때의 작업 속도와 CopyXXX에서 매번 데이터를 수신할 때의 작업 속도를 비교했습니다. 내 버퍼에 대한 호출이 몇 배나 더 빨라졌습니다. 그래서 내 버퍼에 정착했지만 데이터 공급자는 이러한 동일한 버퍼의 중앙 저장소일 뿐입니다.
실제로 "계층"의 존재 - 바로 이 데이터 공급자는 데이터 비동기화의 위험을 초래합니다. 그러나 나는 아직 그런 문제가 발생하지 않았지만 데이터 공급자는 속도를 매우 명확하게 절약합니다. 사실 제 생각에는 이 테스트는 이미 많은 사람들이 했다고 생각합니다. 매번 단말기에 데이터를 문의하는 것보다 틱을 처리할 때 데이터를 한 번 복사해서 사용하는 것이 모두에게 더 유익한 것으로 판명되었습니다.
지금은 다른가요? 그리고 각 이중 값에 대해 CopyXXX를 통한 여러 번 호출의 속도는 전체 범위에 대해 즉시 호출 한 번과 같으며 값에 대한 버퍼 호출은?
아니요, 데이터 공급자에 버퍼를 배치할 때의 작업 속도와 CopyXXX에서 매번 데이터를 수신할 때의 작업 속도를 비교했습니다. 내 버퍼에 대한 호출이 몇 배나 더 빨라졌습니다. 그래서 내 버퍼에 정착했지만 데이터 공급자는 이러한 동일한 버퍼의 중앙 저장소일 뿐입니다.
실제로 "계층"의 존재 - 바로 이 데이터 공급자는 데이터 비동기화의 위험을 초래합니다. 그러나 나는 아직 그런 문제가 발생하지 않았지만 데이터 공급자는 속도를 매우 명확하게 절약합니다. 사실 제 생각에는 이 테스트는 이미 많은 사람들이 했다고 생각합니다. 매번 단말기에 데이터를 문의하는 것보다 틱을 처리할 때 데이터를 한 번 복사해서 사용하는 것이 모두에게 더 유익한 것으로 판명되었습니다.
지금은 다른가요? 그리고 각 이중 값에 대해 CopyXXX를 통한 여러 번 호출의 속도는 전체 범위에 대해 즉시 호출 한 번과 같으며 값에 대한 버퍼 호출은?
의심할 여지 없이 모든 따옴표를 한 번에 전문가(데이터 공급자)의 내부 메모리에 복사한 다음 거기에서 값을 가져오는 것이 CopyBuffer를 지속적으로 호출하는 것보다 훨씬 빠릅니다. 그러나 이것은 국가에 구축된 시스템의 대가입니다. 일반적으로 전체 주제 영역은 Expert Advisors, 스크립트 등을 작성하는 것 입니다. 이것은 상태에 기반한 시스템 프로그래밍입니다. 순서가 있습니다. 유지 관리에 대한 규칙을 처리합니다. 주문이 없습니다 - 우리는 그것을 여는 조건을 봅니다.
CopyBuffer의 경우 큰 따옴표를 복사하고 성능 향상을 측정하는 것은 합성 테스트에서만 가능합니다. 실제로 90%의 경우에 Expert Advisor는 각 눈금의 마지막 막대 또는 새 막대를 여는 순간에 작동합니다. 따라서 마지막 막대에 대한 데이터가 항상 요청되고 마지막 막대를 캐시에 복사하는 CopyBuffer에 대한 지속적인 호출이 있습니다.
유일한 실제 성능 향상은 EA가 N개의 마지막 막대를 필요로 하는 경우입니다. 여기서 N은 1보다 훨씬 큰 숫자입니다. 그러나 N개의 마지막 막대에 대한 요청은 무엇입니까? 이것은 슬라이딩 윈도우에서의 작업입니다(전체 전문가 작업의 99%). 슬라이딩 창은 기본적으로 링 버퍼입니다. 따라서 마지막 N개의 막대를 요청할 때 실제로는 마지막 막대 하나만 업데이트하거나 추가해야 합니다. 저것들. 데이터 블록을 복사하는 이 전체 이야기는 매우 아름다운 이야기이지만 생성된 주제 영역에서는 작동하지 않으며 링 버퍼는 더욱 성공적으로 작동합니다.
지금 내 CSymbol은 올바른 인덱스를 전달하는 것만으로 작동합니다. 그러나 N개의 마지막 막대를 캐시하는 방식으로 현대화할 수 있으며 N은 요청된 최대 인덱스에 따라 Csymbol 자체에서 선택합니다. 그런 다음 외부 변경 없이 일부 작업의 CSymbol은 CopyBuffer에 대한 지속적인 호출보다 몇 배 더 빠르게 작동합니다. 이것이 OOP의 강점입니다. 추가 바인딩 사용과 관련된 특정 오버헤드가 누적된 후 적응형 알고리즘으로 인해 메모리 또는 프로세서 시간 사용을 크게 줄일 수 있을 때 질적 도약이 발생합니다.
엄청난 수의 코드 라인이 있는 EA 코드를 봤습니다. EA가 얼마나 복잡한 디자인으로 설계되었는지 궁금합니다. 아마도 그러한 복잡한 알고리즘으로 작업할 수 있는 도구나 기술이 있을까요?
수백 줄의 코드 블록을 작성합니다. 거의 노코멘트. 아니요. 러시아어 코드. 모든 것이 매우 효율적으로 작동합니다. 약 100개의 연결된 파일이 있지만 프로그램의 방향에는 문제가 없습니다. 아마도 이미 익숙해져서 오랫동안 모든 것을 기억했기 때문일 것입니다. 따라서 가장 중요한 것은 프로그램을 알고 잘 이해하는 것이며 나머지는 부차적입니다. 임호.
수백 줄의 코드 블록을 작성합니다. 거의 노코멘트. 아니요. 러시아어 코드. 모든 것이 매우 효율적으로 작동합니다. 약 100개의 연결된 파일이 있지만 프로그램의 방향에는 문제가 없습니다. 아마도 이미 익숙해져서 오랫동안 모든 것을 기억했기 때문일 것입니다. 따라서 가장 중요한 것은 프로그램을 알고 잘 이해하는 것이며 나머지는 부차적입니다. 임호.
CopyBuffer의 경우 큰 따옴표를 복사하고 성능 향상을 측정하는 것은 합성 테스트에서만 가능합니다. 실제로 90%의 경우에 Expert Advisor는 각 눈금의 마지막 막대 또는 새 막대를 여는 순간에 작동합니다. 따라서 마지막 막대에 대한 데이터가 항상 요청되고 마지막 막대를 캐시에 복사하는 CopyBuffer에 대한 지속적인 호출이 있습니다.
따라서 결국 "종합 테스트"에서 작업 속도가 필요합니다. 전략 테스터 에서 옵션을 반복할 때 속도가 중요합니다. 나에게 속도가 요구되는 "병목 현상"은 전략 테스터다.
실제로 실제 작업에서 CopyXXX를 통한 직접 데이터 액세스 속도는 매번 헤드로 충분합니다. 그러나 테스터에서 실행하려면 속도의 차이가 매우 중요합니다.
따라서 결국 "종합 테스트"에서 작업 속도가 필요합니다. 전략 테스터 에서 옵션을 반복할 때 속도가 중요합니다. 나에게 속도가 요구되는 "병목 현상"은 전략 테스터다.
실제로 실제 작업에서 CopyXXX를 통한 직접 데이터 액세스 속도는 매번 헤드로 충분합니다. 그러나 테스터에서 실행하려면 속도의 차이가 매우 중요합니다.
더 간단하게 설명하겠습니다. 데이터 공급자의 가장 기본에는 맨 마지막 문자를 복사하는 CopyXXX 기능이 있습니다. 내 CSymbol의 맨 아래에는 동일한 마지막 문자를 복사하는 CopyXXX도 있습니다. 두 기능 모두 느립니다. 따라서 귀하와 제 코드 모두 느립니다. CopyXXX 호출을 우회할 수 없습니다. 그러나 내 코드는 더 간단하고 작습니다. 그렇다면 CopyXXX 문제 자체를 해결하지 못한다면 왜 이 모든 다층 추가 기능이 CopyXXX를 통해 이루어지나요?
즉, "ATR이 지표로 간주되지 않는다"는 것은 무엇입니까 ???
그리고 어떻게 "진입 신호로 좋지 않은가요 ??? 그리고 나는 바보입니다, 나는이 지표 만 사용하여 "변동성 분석"엔트리를 사용합니다 ...
지표의 본질에 대한 자신만의 특별한 이해가 있지 않나 생각합니다... 저에게 지표는 시간에 따라 가변적인 가치를 만들어낼 수 있는 객체입니다. 사실 일반 촛대 가격 차트도 지표입니다. 그러나 당신에게 그것은 다른 것입니다. 따라서 우리의 이해는 다릅니다.
사실이라면
표시기 = 무언가의 변경 사항을 보여주는 도구(장치).
이 관점에서 ATP 지표.
내 게시물에서 나는 시장에 진입하기위한 신호 제공자로서의 지표라는 단어를 의미했습니다.(나는 "영구 시장"모드에서 거래하기위한 테스트 지표 에 대해 이야기하고있었습니다). 결과적으로 테이크, 스톱 및 지원 없이 진입 및 반전 신호를 보여야 합니다. 많은 거래 시스템이 있지만 항상 시장에 있는 지표에 순전히 거래할 기회를 찾고 있었습니다. 내가 아는 한 변동성의 분석은 특정 테이크 앤 스톱으로 거래됩니다.
감사합니다.
Я не вижу особой разницы - как я понимаю, WS (WareStore, вероятно ?) - это все тот же мой дата-провайдер.
Work S ymbol 의 약자입니다. 이 개체를 자주 참조하기 때문에 의도적으로 짧은 약어를 선택했습니다.
WS 개체의 초기화에는 몇 가지 예비 단계가 있어야 한다고 생각합니다.
WS에서 이것은 기본 생성자가 현재 Symbol() 기호를 사용하는 CSymbol 개체의 인스턴스입니다. 따라서 WS는 외부에서 초기화할 필요가 없습니다. 단순히 전략 클래스와 함께 생성됩니다.
Expert Advisor에는 서로 다른 기호와 시간대가 포함된 다양한 컨테이너가 있을 수 있습니다. 데이터 제공자의 이념은 복제를 허용하지 않습니다. 실제이기 때문에 모든 시계열이 여기에 저장되고 컨테이너는 단순히 필요한 시계열을 가리킵니다.
결과적으로 전문가 클래스에서 액세스할 수 있는 하나의 메가 클래스 코어가 확보됩니다. MetaTrader 코어와 이에 액세스하는 수백 가지 기능이 있는 경우 이것이 기본 MQL과 어떻게 다릅니까?
MT4-5 자체를 데이터 공급자로 간주하고 액세스를 제공하기 위해서만 클래스를 사용하는 경우 Open 가격에 대한 귀하의 호소에 따라 하나의 값에 대해 CopyOpen() 함수를 호출해야 합니다. 나에게 불합리한.
정확히. 그러한 항소만이 데이터 표현의 통일성과 상태의 완전한 동기화를 보장합니다. 따옴표(잊을 수 있음)를 업데이트할 필요가 없으며, 중간 데이터 웨어하우스를 생성할 때 필연적으로 발생하는 추가 토글 스위치를 사용할 필요가 없습니다. 요청된 데이터와 일치하는 데이터를 데이터베이스에서 검색할 필요가 없습니다. 내 EA가 다음을 수행하는 경우:
그런 다음 그는 WS.High[1]가 거래 환경이 업데이트되는 방식에 관계없이 이전 극값을 자신에게 반환할 것임을 확실히 알고 있습니다. 예, 실행할 때마다 CopyHigh 를 호출하고 단일 double 값을 복사하는 것은 비용이 많이 들지만 100% 신뢰할 수 있습니다. 래퍼 클래스는 데이터를 저장하지 않고 시스템 함수에 대한 호출에만 전달하기 때문에 저장된 데이터가 현재 환경과 일치하지 않는 상황이 발생할 수 없습니다.
또한 프로그램의 모든 변수에 대한 전체 전역 액세스 권한을 부여하는 것은 매우 비합리적이라고 생각합니다. 반대로 프로그램의 모든 위치에서 이 작업에 필요한 구조와 데이터에만 액세스할 수 있도록 노력합니다. 다른 모든 것은 사용할 수 없어야 합니다. 데이터 제공자의 이념은 이 액세스를 제어할 수 있도록 허용합니다.
Georg, 사실 당신은 이미 이 전역 액세스를 생성했습니다. 모든 사람이 요청하는 하나의 큰 슈퍼 클래스 공급자가 있습니다. 이것은 OOP 캔디 래퍼 아래에서 조립되는 하나의 큰 전역 개체 풀(지표, 시계열 등)입니다. 저것들. OOP는 데이터 공급자의 예에서 허구로 변했습니다. 형식적으로 존재하지만 현실에는 존재하지 않는다.
Georg, 사실 당신은 이미 이 전역 액세스를 생성했습니다. 모든 사람이 요청하는 하나의 큰 슈퍼 클래스 공급자가 있습니다. 이것은 OOP 캔디 래퍼 아래에서 조립되는 하나의 큰 전역 개체 풀(지표, 시계열 등)입니다. 저것들. OOP는 데이터 공급자의 예에서 허구로 변했습니다. 형식적으로 존재하지만 현실은 그렇지 않다.
아니요, 데이터 공급자에 버퍼를 배치할 때의 작업 속도와 CopyXXX에서 매번 데이터를 수신할 때의 작업 속도를 비교했습니다. 내 버퍼에 대한 호출이 몇 배나 더 빨라졌습니다. 그래서 내 버퍼에 정착했지만 데이터 공급자는 이러한 동일한 버퍼의 중앙 저장소일 뿐입니다.
실제로 "계층"의 존재 - 바로 이 데이터 공급자는 데이터 비동기화의 위험을 초래합니다. 그러나 나는 아직 그런 문제가 발생하지 않았지만 데이터 공급자는 속도를 매우 명확하게 절약합니다. 사실 제 생각에는 이 테스트는 이미 많은 사람들이 했다고 생각합니다. 매번 단말기에 데이터를 문의하는 것보다 틱을 처리할 때 데이터를 한 번 복사해서 사용하는 것이 모두에게 더 유익한 것으로 판명되었습니다.
지금은 다른가요? 그리고 각 이중 값에 대해 CopyXXX를 통한 여러 번 호출의 속도는 전체 범위에 대해 즉시 호출 한 번과 같으며 값에 대한 버퍼 호출은?
아니요, 데이터 공급자에 버퍼를 배치할 때의 작업 속도와 CopyXXX에서 매번 데이터를 수신할 때의 작업 속도를 비교했습니다. 내 버퍼에 대한 호출이 몇 배나 더 빨라졌습니다. 그래서 내 버퍼에 정착했지만 데이터 공급자는 이러한 동일한 버퍼의 중앙 저장소일 뿐입니다.
실제로 "계층"의 존재 - 바로 이 데이터 공급자는 데이터 비동기화의 위험을 초래합니다. 그러나 나는 아직 그런 문제가 발생하지 않았지만 데이터 공급자는 속도를 매우 명확하게 절약합니다. 사실 제 생각에는 이 테스트는 이미 많은 사람들이 했다고 생각합니다. 매번 단말기에 데이터를 문의하는 것보다 틱을 처리할 때 데이터를 한 번 복사해서 사용하는 것이 모두에게 더 유익한 것으로 판명되었습니다.
지금은 다른가요? 그리고 각 이중 값에 대해 CopyXXX를 통한 여러 번 호출의 속도는 전체 범위에 대해 즉시 호출 한 번과 같으며 값에 대한 버퍼 호출은?
의심할 여지 없이 모든 따옴표를 한 번에 전문가(데이터 공급자)의 내부 메모리에 복사한 다음 거기에서 값을 가져오는 것이 CopyBuffer를 지속적으로 호출하는 것보다 훨씬 빠릅니다. 그러나 이것은 국가에 구축된 시스템의 대가입니다. 일반적으로 전체 주제 영역은 Expert Advisors, 스크립트 등을 작성하는 것 입니다. 이것은 상태에 기반한 시스템 프로그래밍입니다. 순서가 있습니다. 유지 관리에 대한 규칙을 처리합니다. 주문이 없습니다 - 우리는 그것을 여는 조건을 봅니다.
CopyBuffer의 경우 큰 따옴표를 복사하고 성능 향상을 측정하는 것은 합성 테스트에서만 가능합니다. 실제로 90%의 경우에 Expert Advisor는 각 눈금의 마지막 막대 또는 새 막대를 여는 순간에 작동합니다. 따라서 마지막 막대에 대한 데이터가 항상 요청되고 마지막 막대를 캐시에 복사하는 CopyBuffer에 대한 지속적인 호출이 있습니다.
유일한 실제 성능 향상은 EA가 N개의 마지막 막대를 필요로 하는 경우입니다. 여기서 N은 1보다 훨씬 큰 숫자입니다. 그러나 N개의 마지막 막대에 대한 요청은 무엇입니까? 이것은 슬라이딩 윈도우에서의 작업입니다(전체 전문가 작업의 99%). 슬라이딩 창은 기본적으로 링 버퍼입니다. 따라서 마지막 N개의 막대를 요청할 때 실제로는 마지막 막대 하나만 업데이트하거나 추가해야 합니다. 저것들. 데이터 블록을 복사하는 이 전체 이야기는 매우 아름다운 이야기이지만 생성된 주제 영역에서는 작동하지 않으며 링 버퍼는 더욱 성공적으로 작동합니다.
지금 내 CSymbol은 올바른 인덱스를 전달하는 것만으로 작동합니다. 그러나 N개의 마지막 막대를 캐시하는 방식으로 현대화할 수 있으며 N은 요청된 최대 인덱스에 따라 Csymbol 자체에서 선택합니다. 그런 다음 외부 변경 없이 일부 작업의 CSymbol은 CopyBuffer에 대한 지속적인 호출보다 몇 배 더 빠르게 작동합니다. 이것이 OOP의 강점입니다. 추가 바인딩 사용과 관련된 특정 오버헤드가 누적된 후 적응형 알고리즘으로 인해 메모리 또는 프로세서 시간 사용을 크게 줄일 수 있을 때 질적 도약이 발생합니다.
안녕하세요.
수백 줄의 코드 블록을 작성합니다. 거의 노코멘트. 아니요. 러시아어 코드. 모든 것이 매우 효율적으로 작동합니다. 약 100개의 연결된 파일이 있지만 프로그램의 방향에는 문제가 없습니다. 아마도 이미 익숙해져서 오랫동안 모든 것을 기억했기 때문일 것입니다. 따라서 가장 중요한 것은 프로그램을 알고 잘 이해하는 것이며 나머지는 부차적입니다. 임호.
수백 줄의 코드 블록을 작성합니다. 거의 노코멘트. 아니요. 러시아어 코드. 모든 것이 매우 효율적으로 작동합니다. 약 100개의 연결된 파일이 있지만 프로그램의 방향에는 문제가 없습니다. 아마도 이미 익숙해져서 오랫동안 모든 것을 기억했기 때문일 것입니다. 따라서 가장 중요한 것은 프로그램을 알고 잘 이해하는 것이며 나머지는 부차적입니다. 임호.
1C에서 MQL로 오셨습니까?
독학했어요. 내가 마스터한 첫 번째 프로그래밍 언어는 MQL4였습니다. C # 및 C ++에 대한 약간의 연습 후.
1에 대해 들어본 적이 없습니다. 그것은 무엇입니까?
CopyBuffer의 경우 큰 따옴표를 복사하고 성능 향상을 측정하는 것은 합성 테스트에서만 가능합니다. 실제로 90%의 경우에 Expert Advisor는 각 눈금의 마지막 막대 또는 새 막대를 여는 순간에 작동합니다. 따라서 마지막 막대에 대한 데이터가 항상 요청되고 마지막 막대를 캐시에 복사하는 CopyBuffer에 대한 지속적인 호출이 있습니다.
따라서 결국 "종합 테스트"에서 작업 속도가 필요합니다. 전략 테스터 에서 옵션을 반복할 때 속도가 중요합니다. 나에게 속도가 요구되는 "병목 현상"은 전략 테스터다.
실제로 실제 작업에서 CopyXXX를 통한 직접 데이터 액세스 속도는 매번 헤드로 충분합니다. 그러나 테스터에서 실행하려면 속도의 차이가 매우 중요합니다.
따라서 결국 "종합 테스트"에서 작업 속도가 필요합니다. 전략 테스터 에서 옵션을 반복할 때 속도가 중요합니다. 나에게 속도가 요구되는 "병목 현상"은 전략 테스터다.
실제로 실제 작업에서 CopyXXX를 통한 직접 데이터 액세스 속도는 매번 헤드로 충분합니다. 그러나 테스터에서 실행하려면 속도의 차이가 매우 중요합니다.
더 간단하게 설명하겠습니다. 데이터 공급자의 가장 기본에는 맨 마지막 문자를 복사하는 CopyXXX 기능이 있습니다. 내 CSymbol의 맨 아래에는 동일한 마지막 문자를 복사하는 CopyXXX도 있습니다. 두 기능 모두 느립니다. 따라서 귀하와 제 코드 모두 느립니다. CopyXXX 호출을 우회할 수 없습니다. 그러나 내 코드는 더 간단하고 작습니다. 그렇다면 CopyXXX 문제 자체를 해결하지 못한다면 왜 이 모든 다층 추가 기능이 CopyXXX를 통해 이루어지나요?