HistorySelect 는 선택한 히스토리의 물리적 스냅샷을 Expert Advisor의 로컬 캐시에 만들어 사용자가 두려움 없이 정렬할 수 있도록 합니다. 이것이 없으면 계정 기록이 비동기식으로 업데이트/동기화되기 때문에 매우 불쾌한 효과를 얻을 수 있습니다. 이것은 사용자 자신이 인터페이스에서 기록의 깊이를 수동으로 변경할 수 있다는 사실은 말할 것도 없습니다.
따라서 복사에 대한 이러한 비용. 특히 이 기록을 여러 스레드에서 캐시로 동시 강제 복사하는 경우 특히 그렇습니다.
우리는 이미 가져오기 작업을 많이 최적화했으며 이제 최적의 캐시 업데이트에 대해 생각하고 있습니다. 실제로 가져오기의 99%가 완전히 쓸모없고 실제로 건너뛸 때입니다.
즉, 샘플 제한을 의도적으로 무작위화하지 않으면 캐시에 100%에 가까운 적중이 표시됩니다.
HistorySelect는 선택한 히스토리의 물리적 스냅샷을 Expert Advisor의 로컬 캐시에 만들어 사용자가 두려움 없이 정렬할 수 있도록 합니다. 이것이 없으면 계정 기록이 비동기식으로 업데이트/동기화되기 때문에 매우 불쾌한 효과를 얻을 수 있습니다. 이것은 사용자 자신이 인터페이스에서 기록의 깊이를 수동으로 변경할 수 있다는 사실은 말할 것도 없습니다.
주문 테이블과 거래 테이블이 있습니다. HistorySelect를 호출할 때 4개의 인덱스를 아는 것으로 충분할 때 물리적 스냅을 수행하는 이유는 무엇입니까?
따라서 복사에 대한 이러한 비용. 특히 이 기록을 여러 스레드에서 캐시로 동시에 강제 복사하는 것을 특별히 처리하는 경우.
우리는 이미 가져오기 작업을 많이 최적화했으며 이제 최적의 캐시 업데이트에 대해 생각하고 있습니다. 실제로 가져오기의 99%가 완전히 쓸모없고 실제로 건너뛸 때입니다.
즉, 샘플 제한을 특별히 무작위화하지 않으면 캐시에 100%에 가까운 적중이 표시됩니다.
아마도 다음 주에 효과적인 해결책이 나올 것입니다.
HistoryDealSelect 및 HistoryOrderSelect는 이제 각각의 선택을 파괴합니다. MT4에서와 같이 인덱스로 두 테이블에 모두 액세스할 수 없는 이유는 무엇입니까? 새로운 기능을 소개합니다.
비동기 작업, 동기화 프로세스 및 사용자가 설정한 수동 깊이 모드로 인해 누구도 불변성을 보장할 수 없습니다.
위에서 쓴 것처럼 스마트 캐싱 방법을 적용하여 Select 함수의 비용을 0으로 줄입니다. 물론 샘플 제한을 의도적으로 무작위화하지 않는 한. 마지막 날짜는 변경될 수 있으며 항상 미래/마지막 시간인 경우 캐시를 무효화하지 않습니다. 최신 트랜잭션이 캐시에 드물게 추가됩니다.
MT4에서는 동일하게 작동하며 캐시 생성만 숨겨집니다. 각 OnTick/OnStart MT4에서 단말기는 각 전문가에 대한 시장 환경의 스냅샷을 자동으로 경제적으로 생성합니다.
따라서 MQL4 코드에서 데이터를 준비할 때 실제 지연을 추정할 수 없습니다. 다행히 MT4에는 데이터가 거의 없고 모든 것이 간단합니다.
MT5에서는 지연을 줄이고 불필요한 작업을 피하기 위해 자동으로 시장 환경을 만드는 비용을 제거했습니다. 대신, 우리는 그들이 필요한 것을 정확히 요청할 수 있는 로봇 개발자에게 총 비용 관리를 제공했습니다.
Renat, Copy.. 기능을 사용할 때 TERMINAL_MAXBARS 외부의 따옴표에 액세스할 수 있는 큰 요청입니다. 최소 1분의 시간 프레임. 이를 위해 별도의 기능을 만들 수 있습니다. 이 데이터에 액세스하려면 TERMINAL_MAXBARS를 무제한으로(터미널 과부하가 있는 경우에도) 지속적으로 설정해야 하므로 매우 불편합니다. 모든 문자에 무제한이 필요하지 않습니다. 결국 내가 이해하는 한 해당 기간의 몇 가지 MN1 마디를 모두 복사하면 모든 M1 마디가 여전히 다운로드되지만 액세스할 수는 없습니다. 물론 모든 틱을 다운로드할 수 있습니다. 그들은 이 제한의 대상이 아니지만 시간이 더 오래 걸리고 불행히도 틱이 전체 분 기록과 항상 일치하지는 않습니다.
Renat, Copy.. 기능을 사용할 때 TERMINAL_MAXBARS 외부의 따옴표에 액세스할 수 있는 큰 요청입니다. 최소 1분의 시간 프레임. 이를 위해 별도의 기능을 만들 수 있습니다. 이 데이터에 액세스하려면 TERMINAL_MAXBARS를 무제한으로(터미널 과부하가 있는 경우에도) 지속적으로 설정해야 하므로 매우 불편합니다. 모든 문자에 무제한이 필요하지 않습니다. 결국 내가 이해하는 한 해당 기간의 몇 가지 MN1 마디를 모두 복사하면 모든 M1 마디가 여전히 다운로드되지만 액세스할 수는 없습니다. 물론 모든 틱을 다운로드할 수 있습니다. 그들은 이 제한의 대상이 아니지만 시간이 더 오래 걸리고 불행히도 틱이 전체 분 기록과 항상 일치하지는 않습니다.
아니요, 이 제한을 초과하는 기록은 발생하지 않으며 동기화를 위해 확인되지 않습니다. 또한 저장할 곳이 없으며 (추가 보이지 않는 캐시를 만들지 않음) 낭비 모드로 디스크를 오르지 않고 목발을 만들지 않습니다.
일반적으로 이것은 해로운 생각입니다. 개발자는 즉시 절대적으로 비효율적인 알고리즘을 작성하기 시작하여 거래자에게 "5000개 이상 1000개 막대를 넣어"라고 조언하고 브레이크와 비효율성을 비난할 것이기 때문입니다.
특히 차트의 리소스 양을 제어할 수 있도록 했습니다. 이제 64비트이고 메모리가 저렴합니다. 규칙 및 아키텍처 내에서 적절한 설정을 사용하십시오.
아니요, 이 제한을 초과하는 기록은 발생하지 않으며 동기화를 위해 확인되지 않습니다. 또한 저장할 곳이 없으며 (추가 보이지 않는 캐시를 만들지 않음) 낭비 모드에서 디스크를 오르지 않을 것입니다.
일반적으로 이것은 해로운 생각입니다. 개발자는 즉시 절대적으로 비효율적인 알고리즘을 작성하기 시작하여 거래자에게 "5000 또는 더 나은 1000 막대를 설정"하고 브레이크와 비효율성을 비난하도록 조언할 것이기 때문입니다.
특히 차트의 리소스 양을 제어할 수 있도록 했습니다. 이제 64비트이고 메모리가 저렴합니다. 규칙 및 아키텍처 내에서 적절한 설정을 사용하십시오.
우리는 이 동작을 변경하지 않을 것입니다.
확인. 이해했다. 고맙습니다. 나는 긋는다. 물론 나는 낭비에 대해 논쟁하고 싶습니다. 나는 무제한으로 남겨 두어야 할 것이고 결과적으로 모든 열린 차트 (예 : 현재 14 개의 차트가 있음)는 전체 무제한 기록을 저장하지만 5000 만 있으면 충분합니다. 반대로 더 많을 것입니다. 비경제적. 또한 이 데이터를 저장할 필요가 없습니다. 보관은 제가 알아서 하겠습니다. 모든 분 막대의 다운로드를 시작하여 어레이에 가져왔고 더 이상 필요하지 않으며 크기가 TERMINAL_MAXBARS를 초과하면 모든 캐시를 삭제할 수 있습니다. 따라서 이를 위해 캐시를 저장하지 않는 별도의 기능이 필요할 수 있습니다.
물론, 나는 장난기 많은 펜이 그러한 주기적 다운로드로 시스템을 중단시킬 수 있다는 데 동의합니다.
HistorySelect 는 선택한 히스토리의 물리적 스냅샷을 Expert Advisor의 로컬 캐시에 만들어 사용자가 두려움 없이 정렬할 수 있도록 합니다. 이것이 없으면 계정 기록이 비동기식으로 업데이트/동기화되기 때문에 매우 불쾌한 효과를 얻을 수 있습니다. 이것은 사용자 자신이 인터페이스에서 기록의 깊이를 수동으로 변경할 수 있다는 사실은 말할 것도 없습니다.
따라서 복사에 대한 이러한 비용. 특히 이 기록을 여러 스레드에서 캐시로 동시 강제 복사하는 경우 특히 그렇습니다.
우리는 이미 가져오기 작업을 많이 최적화했으며 이제 최적의 캐시 업데이트에 대해 생각하고 있습니다. 실제로 가져오기의 99%가 완전히 쓸모없고 실제로 건너뛸 때입니다.
즉, 샘플 제한을 의도적으로 무작위화하지 않으면 캐시에 100%에 가까운 적중이 표시됩니다.
아마도 다음 주에 효과적인 해결책이 나올 것입니다.
HistorySelect는 선택한 히스토리의 물리적 스냅샷을 Expert Advisor의 로컬 캐시에 만들어 사용자가 두려움 없이 정렬할 수 있도록 합니다. 이것이 없으면 계정 기록이 비동기식으로 업데이트/동기화되기 때문에 매우 불쾌한 효과를 얻을 수 있습니다. 이것은 사용자 자신이 인터페이스에서 기록의 깊이를 수동으로 변경할 수 있다는 사실은 말할 것도 없습니다.
주문 테이블과 거래 테이블이 있습니다. HistorySelect를 호출할 때 4개의 인덱스를 아는 것으로 충분할 때 물리적 스냅을 수행하는 이유는 무엇입니까?
따라서 복사에 대한 이러한 비용. 특히 이 기록을 여러 스레드에서 캐시로 동시에 강제 복사하는 것을 특별히 처리하는 경우.
우리는 이미 가져오기 작업을 많이 최적화했으며 이제 최적의 캐시 업데이트에 대해 생각하고 있습니다. 실제로 가져오기의 99%가 완전히 쓸모없고 실제로 건너뛸 때입니다.
즉, 샘플 제한을 특별히 무작위화하지 않으면 캐시에 100%에 가까운 적중이 표시됩니다.
아마도 다음 주에 효과적인 해결책이 나올 것입니다.
HistoryDealSelect 및 HistoryOrderSelect는 이제 각각의 선택을 파괴합니다. MT4에서와 같이 인덱스로 두 테이블에 모두 액세스할 수 없는 이유는 무엇입니까? 새로운 기능을 소개합니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
오류, 버그, 질문
fxsaber , 2020.08.20 11:28
새로운 표준 기능.인덱스가 묻습니다. 한 곳에서 계정의 거래 건수를 알아야 하는 이유가 전혀 명확하지 않습니다.
그리고 이러한 테이블은 언제든지 변경될 수 있습니다. 뿐만 아니라 개별 항목.
비동기 작업, 동기화 프로세스 및 사용자가 설정한 수동 깊이 모드로 인해 누구도 불변성을 보장할 수 없습니다.
위에서 쓴 것처럼 스마트 캐싱 방법을 적용하여 Select 함수의 비용을 0으로 줄입니다. 물론 샘플 제한을 의도적으로 무작위화하지 않는 한. 마지막 날짜는 변경될 수 있으며 항상 미래/마지막 시간인 경우 캐시를 무효화하지 않습니다. 최신 트랜잭션이 캐시에 드물게 추가됩니다.
MT4에서는 동일하게 작동하며 캐시 생성만 숨겨집니다. 각 OnTick/OnStart MT4에서 단말기는 각 전문가에 대한 시장 환경의 스냅샷을 자동으로 경제적으로 생성합니다.
따라서 MQL4 코드에서 데이터를 준비할 때 실제 지연을 추정할 수 없습니다. 다행히 MT4에는 데이터가 거의 없고 모든 것이 간단합니다.
MT5에서는 지연을 줄이고 불필요한 작업을 피하기 위해 자동으로 시장 환경을 만드는 비용을 제거했습니다. 대신, 우리는 그들이 필요한 것을 정확히 요청할 수 있는 로봇 개발자에게 총 비용 관리를 제공했습니다.
MT5의 시장 환경 규모는 MT4에 비해 엄청납니다. 단순히 복제할 수 없습니다.
테스트에서 이러한 값비싼 샘플 중 하나를 사용했습니다.
우리가 고칠 것입니다 - 그것은 우리의 관심사입니다.
그리고 이 테이블은 언제든지 변경될 수 있습니다. 뿐만 아니라 개별 항목.
비동기 작업, 동기화 프로세스 및 사용자가 설정한 수동 깊이 모드로 인해 누구도 불변성을 보장할 수 없습니다.
거래 역사상 마지막 거래 전에 다른 거래가 나타날 수 있다고 말하고 싶습니까? 거래가 변경되면 다릅니다. 그러나 이미 존재하는 목록 내부에 끼어들기 위해 - 이것을 눈치채지 못했습니다.
OrderExist 및 PositionExist는 기호, 작업 유형 및 마법으로 레코드를 검색할 때 모든 주문 또는 위치의 루프에서 어리석은 반복을 피할 수 있도록 하는 특별히 최적화된 기능입니다.
결과적으로 티켓이 있는 배열을 얻습니다.
프로그램은 이러한 기능을 사용하여 많은 비용을 절약할 수 있습니다. 특히 그들이 열거 주기에서 열린 위치와 주문에 대규모로 지속적으로 반복적으로 액세스할 때.
앞으로 대규모 거래 데이터에 접근하기 위한 보다 효율적인 기능을 구현할 것입니다.
언어는 또한 더 강력한 기능으로 크게 증가하고 단순화할 것입니다.
거래 역사상 마지막 거래 전에 다른 거래가 나타날 수 있다고 말하고 싶습니까? 거래가 변경되면 다릅니다. 그러나 이미 존재하는 목록 내부에 끼어들기 위해 - 이것을 눈치채지 못했습니다.
이론적으로 그렇습니다.
동기화 프로세스를 잊지 마십시오. 플랫폼의 수많은 프로세스가 비동기식입니다.
예를 들어, 거래소 또는 유동성 공급자가 있는 통합 게이트웨이는 몇 초 또는 몇 분의 지연이 있는 트랜잭션에 대한 보고서를 보낼 수 있습니다. 종종 api는 확인을 위해 기록에 대한 액세스를 전혀 제공하지 않지만 느리고 비실시간 보고서 생성기를 제공합니다.
개장 시 또는 예상치 못한 게이트웨이 재접속으로 인해 보고가 지연될 수 있습니다. 그것들은 서버의 히스토리에 복제되고 터미널에 비동기식으로 즉시 전송됩니다. 날짜순으로 정렬되어 있기 때문에 올바른 위치에 삽입되며 이때 새로운 거래를 열 수 있습니다.
대부분의 통합 API는 문맹이고 작동하지 않기 때문에 보장된 게이트웨이를 만드는 것이 거의 불가능합니다. 이것이 개발자의 고의적인 방해 행위의 산물이라는 의견이 있지만.
OrderExist 및 PositionExist는 기호, 작업 유형 및 마법으로 레코드를 검색할 때 모든 주문 또는 위치의 루프에서 어리석은 반복을 피할 수 있도록 하는 특별히 최적화된 기능입니다.
결과적으로 티켓이 있는 배열을 얻습니다.
프로그램은 이러한 기능을 사용하여 많은 비용을 절약할 수 있습니다. 특히 그들이 열거 주기에서 열린 위치와 주문에 대규모로 지속적으로 반복적으로 액세스할 때.
앞으로 대규모 거래 데이터에 접근하기 위한 보다 효율적인 기능을 구현할 것입니다.
언어는 또한 더 강력한 기능으로 크게 증가하고 단순화할 것입니다.
Renat, Copy.. 기능을 사용할 때 TERMINAL_MAXBARS 외부의 따옴표에 액세스할 수 있는 큰 요청입니다. 최소 1분의 시간 프레임. 이를 위해 별도의 기능을 만들 수 있습니다.
이 데이터에 액세스하려면 TERMINAL_MAXBARS를 무제한으로(터미널 과부하가 있는 경우에도) 지속적으로 설정해야 하므로 매우 불편합니다. 모든 문자에 무제한이 필요하지 않습니다.
결국 내가 이해하는 한 해당 기간의 몇 가지 MN1 마디를 모두 복사하면 모든 M1 마디가 여전히 다운로드되지만 액세스할 수는 없습니다.
물론 모든 틱을 다운로드할 수 있습니다. 그들은 이 제한의 대상이 아니지만 시간이 더 오래 걸리고 불행히도 틱이 전체 분 기록과 항상 일치하지는 않습니다.
Renat, Copy.. 기능을 사용할 때 TERMINAL_MAXBARS 외부의 따옴표에 액세스할 수 있는 큰 요청입니다. 최소 1분의 시간 프레임. 이를 위해 별도의 기능을 만들 수 있습니다.
이 데이터에 액세스하려면 TERMINAL_MAXBARS를 무제한으로(터미널 과부하가 있는 경우에도) 지속적으로 설정해야 하므로 매우 불편합니다. 모든 문자에 무제한이 필요하지 않습니다.
결국 내가 이해하는 한 해당 기간의 몇 가지 MN1 마디를 모두 복사하면 모든 M1 마디가 여전히 다운로드되지만 액세스할 수는 없습니다.
물론 모든 틱을 다운로드할 수 있습니다. 그들은 이 제한의 대상이 아니지만 시간이 더 오래 걸리고 불행히도 틱이 전체 분 기록과 항상 일치하지는 않습니다.
아니요, 이 제한을 초과하는 기록은 발생하지 않으며 동기화를 위해 확인되지 않습니다. 또한 저장할 곳이 없으며 (추가 보이지 않는 캐시를 만들지 않음) 낭비 모드로 디스크를 오르지 않고 목발을 만들지 않습니다.
일반적으로 이것은 해로운 생각입니다. 개발자는 즉시 절대적으로 비효율적인 알고리즘을 작성하기 시작하여 거래자에게 "5000개 이상 1000개 막대를 넣어"라고 조언하고 브레이크와 비효율성을 비난할 것이기 때문입니다.
특히 차트의 리소스 양을 제어할 수 있도록 했습니다. 이제 64비트이고 메모리가 저렴합니다. 규칙 및 아키텍처 내에서 적절한 설정을 사용하십시오.
우리는 이 동작을 변경하지 않을 것입니다.
아니요, 이 제한을 초과하는 기록은 발생하지 않으며 동기화를 위해 확인되지 않습니다. 또한 저장할 곳이 없으며 (추가 보이지 않는 캐시를 만들지 않음) 낭비 모드에서 디스크를 오르지 않을 것입니다.
일반적으로 이것은 해로운 생각입니다. 개발자는 즉시 절대적으로 비효율적인 알고리즘을 작성하기 시작하여 거래자에게 "5000 또는 더 나은 1000 막대를 설정"하고 브레이크와 비효율성을 비난하도록 조언할 것이기 때문입니다.
특히 차트의 리소스 양을 제어할 수 있도록 했습니다. 이제 64비트이고 메모리가 저렴합니다. 규칙 및 아키텍처 내에서 적절한 설정을 사용하십시오.
우리는 이 동작을 변경하지 않을 것입니다.
확인. 이해했다. 고맙습니다. 나는 긋는다.
물론 나는 낭비에 대해 논쟁하고 싶습니다. 나는 무제한으로 남겨 두어야 할 것이고 결과적으로 모든 열린 차트 (예 : 현재 14 개의 차트가 있음)는 전체 무제한 기록을 저장하지만 5000 만 있으면 충분합니다. 반대로 더 많을 것입니다. 비경제적.
또한 이 데이터를 저장할 필요가 없습니다. 보관은 제가 알아서 하겠습니다. 모든 분 막대의 다운로드를 시작하여 어레이에 가져왔고 더 이상 필요하지 않으며 크기가 TERMINAL_MAXBARS를 초과하면 모든 캐시를 삭제할 수 있습니다. 따라서 이를 위해 캐시를 저장하지 않는 별도의 기능이 필요할 수 있습니다.
물론, 나는 장난기 많은 펜이 그러한 주기적 다운로드로 시스템을 중단시킬 수 있다는 데 동의합니다.
상태 5000과 unlim이 두 개뿐입니까?
당신은 당신 자신의 행복의 건축가입니다.