많은 사람들이 재현할 수 있는 순수한 MQL5 코드가 있었습니다. 먼저 지부의 연대기를 연구하고, 누군가가 당신을 너무 많이 필요로 하여 당신에게 진흙을 쏟아 붓는 데 시간을 할애할 준비가 되어 있다는 음모론을 연주하지 마십시오.
당신은 칠면조의 역할을 훌륭하게 수행하고 있습니다. 여기, 특히 분기에서 라이브러리에 대한 이야기는 없었습니다. tk. 건설적이지 않습니다.
요점은 누군가 from-input 매개변수가 일치하지 않는 라이브러리를 공유하기로 결정하면 제동이 걸린다는 것입니다. 문서 어디에도 이에 대한 언급은 없습니다. 적어도 이 주제에 대한 무언가가 당신에게서 진드기로 제거되었습니다. 그리고 그들이 그것을 꺼냈을 때, 부정 행위의 비난이있었습니다.
MQL의 이 기능은 문서 및 기능 스레드로 구워야 합니다. 작성된 날짜에 해당하는 빌드에서 이 분기의 순수 MQL5 스크립트를 실행하십시오. 만일을 대비하여 맹목적으로 수정을 많이 한 것 같습니다.
당신은 칠면조의 역할을 훌륭하게 수행하고 있습니다. 여기, 특히 분기에서 라이브러리에 대한 이야기는 없었습니다. tk. 건설적이지 않습니다.
도서관이 미끄러지지 않도록최선을 다했기 때문입니다. 이러한 라이브러리와 함께. "내가 더 빠르다"는 끊임없는 반대와 함께. 따라서 석궁은 교활하게 위장되어 "속도가 어떻게 느려지는지보십시오".
요점은 누군가 from-input 매개변수가 일치하지 않는 라이브러리를 공유하기로 결정하면 제동이 걸린다는 것입니다. 문서 어디에도 이에 대한 언급은 없습니다. 적어도 이 주제에 관한 무언가가 당신에게서 진드기로 제거되었습니다. 그리고 그것을 꺼냈을 때 부정 행위의 혐의가있었습니다.
MQL의 이 기능은 문서 및 기능 스레드로 구워야 합니다. 작성된 날짜에 해당하는 빌드에서 이 분기의 순수 MQL5 스크립트를 실행하십시오. 만일을 대비하여 맹목적으로 수정을 많이 한 것 같습니다.
HistoryOrderSelect() 함수를 적용한 후 mql5 프로그램에서 사용할 수 있는 히스토리의 주문 목록이 재설정 되고 티켓별 주문 검색 이 성공한 경우 찾은 주문으로 다시 채워집니다. mql5 프로그램에서 사용할 수 있는 거래 목록에도 동일하게 적용됩니다. 이는 HistoryDealSelect() 함수에 의해 재설정되고 티켓 번호로 거래를 성공적으로 수신한 경우 다시 채워집니다.
원자성/스냅샷 액세스가 필요한 방대한 양의 작업(그리고 역사적으로 수천 수만 건의 거래를 표시한 경우)을 처리하는 경우 해당 비용을 이해해야 합니다.
또한이 항목에서 이러한 캐시 작업의 기술적 세부 사항에 대해 자세히 설명했습니다.
각 샘플을 무작위로 추출하고 가능한 한 많은 캐시를 독살하려고 했으나 헛수고였습니까 ? 당신의 입장을 위해, 주제에 석궁이 있습니까?
HistoryOrderSelect() 함수를 적용한 후 mql5 프로그램에서 사용할 수 있는 히스토리의 주문 목록이 재설정 되고 티켓별 주문 검색 이 성공한 경우 찾은 주문으로 다시 채워집니다. mql5 프로그램에서 사용할 수 있는 거래 목록에도 동일하게 적용됩니다. 이는 HistoryDealSelect() 함수에 의해 재설정되고 티켓 번호로 거래를 성공적으로 수신한 경우 다시 채워집니다.
이 텍스트에서 줄 사이에 무언가를 본 사람이 누구인지 궁금합니다. 개인적으로 나는 (이 스레드 이전에) HistoryDealSelect와 HistoryOrderSelect가 다음과 같이 작성되어야 한다는 것을 이해했습니다.
전체 기록이 다시 요청될 때 터미널이 캐시를 늘리고 누락된 범위를 가져와 캐시할 수 없는 이유는 무엇입니까?
이미 완료되었습니다.
그러나 HistorySelect( other_time, ... )가 HistorySelect( 0, INT_MAX ) 호출 사이에 호출되면 캐시가 other_time부터 다시 작성되고 다음 HistorySelect( 0, ... ) 요청으로 인해 캐시가 다시 작성됩니다( 더 느림).
그러나 HistorySelect( other_time, ... )가 HistorySelect( 0, INT_MAX ) 호출 사이에 호출되면 캐시가 other_time부터 다시 작성되고 다음 HistorySelect( 0, ... ) 요청으로 인해 캐시가 다시 작성됩니다( 더 느림).
그렇다면 좋은 것입니다. 유일한 질문은 캐시의 증가에 따라 수신된 데이터 작업의 편의성입니다.
거래 조작을 그렇게 깊이 이해하지 못했는데 요청 범위가 변경되면 전체 열거 없이 히스토리 내 데이터를 빠르게 검색할 가능성이 없다는 의미입니까?
누군가가 이해하지 못한다면 이것은 fxsaber 라이브러리이며 다른 사람의 코드에서 사용될 때 제동을 겁니다.
명시적으로 지적하는 대신 플랫폼 브레이크 게임을 하고 자살을 시도하기 시작했습니다. 그리고 진짜 이유를 찾아 문제를 수습할 수 있는 기회가 생겼을 때 이를 이용하지 않았다.
로컬 최적화를 위해 메인 애플리케이션의 히스토리 캐시를 감염시켰습니다.거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
MT5와 속도
fxsaber , 2020.09.02 00:02
많은 사람들이 재현할 수 있는 순수한 MQL5 코드가 있었습니다. 먼저 지부의 연대기를 연구하고, 누군가가 당신을 너무 많이 필요로 하여 당신에게 진흙을 쏟아 붓는 데 시간을 할애할 준비가 되어 있다는 음모론을 연주하지 마십시오.
당신은 칠면조의 역할을 훌륭하게 수행하고 있습니다. 여기, 특히 분기에서 라이브러리에 대한 이야기는 없었습니다. tk. 건설적이지 않습니다.
요점은 누군가 from-input 매개변수가 일치하지 않는 라이브러리를 공유하기로 결정하면 제동이 걸린다는 것입니다. 문서 어디에도 이에 대한 언급은 없습니다. 적어도 이 주제에 대한 무언가가 당신에게서 진드기로 제거되었습니다. 그리고 그들이 그것을 꺼냈을 때, 부정 행위의 비난이있었습니다.
MQL의 이 기능은 문서 및 기능 스레드로 구워야 합니다. 작성된 날짜에 해당하는 빌드에서 이 분기의 순수 MQL5 스크립트를 실행하십시오. 만일을 대비하여 맹목적으로 수정을 많이 한 것 같습니다.
당신은 칠면조의 역할을 훌륭하게 수행하고 있습니다. 여기, 특히 분기에서 라이브러리에 대한 이야기는 없었습니다. tk. 건설적이지 않습니다.
도서관이 미끄러지지 않도록 최선을 다했기 때문입니다. 이러한 라이브러리와 함께. "내가 더 빠르다"는 끊임없는 반대와 함께. 따라서 석궁은 교활하게 위장되어 "속도가 어떻게 느려지는지보십시오".
요점은 누군가 from-input 매개변수가 일치하지 않는 라이브러리를 공유하기로 결정하면 제동이 걸린다는 것입니다. 문서 어디에도 이에 대한 언급은 없습니다. 적어도 이 주제에 관한 무언가가 당신에게서 진드기로 제거되었습니다. 그리고 그것을 꺼냈을 때 부정 행위의 혐의가있었습니다.
MQL의 이 기능은 문서 및 기능 스레드로 구워야 합니다. 작성된 날짜에 해당하는 빌드에서 이 분기의 순수 MQL5 스크립트를 실행하십시오. 만일을 대비하여 맹목적으로 수정을 많이 한 것 같습니다.
HistorySelect 문서 에는 다음과 같이 명시되어 있습니다.
원자성/스냅샷 액세스가 필요한 방대한 양의 작업(그리고 역사적으로 수천 수만 건의 거래를 표시한 경우)을 처리하는 경우 해당 비용을 이해해야 합니다.
또한이 항목에서 이러한 캐시 작업의 기술적 세부 사항에 대해 자세히 설명했습니다.
각 샘플을 무작위로 추출하고 가능한 한 많은 캐시를 독살하려고 했으나 헛수고였습니까 ? 당신의 입장을 위해, 주제에 석궁이 있습니까?
도서관이 미끄러지지 않도록 최선을 다했기 때문입니다. 따라서 석궁은 교활하게 위장되어 "속도가 어떻게 느려지는지 확인하십시오."
99%의 버그가 이렇게 발견됩니다. 첫째, 큰 코드에는 이상한 동작이 있습니다. 그런 다음 현지화를 통해 원인을 찾습니다. 나는 이 브레이크에 대해 더 걱정했다.
거래 기능 이 없습니다. 문제는 거의 모든 곳에 있습니다.
HistorySelect 문서 에는 다음과 같이 명시되어 있습니다.
이 텍스트에서 줄 사이에 무언가를 본 사람이 누구인지 궁금합니다. 개인적으로 나는 (이 스레드 이전에) HistoryDealSelect와 HistoryOrderSelect가 다음과 같이 작성되어야 한다는 것을 이해했습니다.
그렇지 않으면 브레이크를 밟을 수 있습니다.
원자/스냅샷 액세스가 필요한 거대한 볼륨으로 작업하는 경우 비용을 이해해야 합니다.
또한이 항목에서 이러한 캐시 작업의 기술적 세부 사항에 대해 자세히 설명했습니다.
이 스레드에서 필요한 정보를 틱으로 꺼냈습니다.
각 샘플을 무작위로 추출하고 가능한 한 많은 캐시를 독살하려고 했으나 헛수고였습니까 ? 당신의 입장을 위해, 주제에 석궁이 있습니까?
이 스레드의 모든 것을 시간순으로 볼 수 있습니다. 처음에는 문제가 임의성 없이 표시되었습니다 .
이 스레드는 상대방의 말을 어떻게 왜곡할 수 있는지에 대한 훌륭한 증거입니다. 모든 소스와 실행 결과가 여기에 저장됩니다.
전체 기록이 다시 요청될 때 터미널이 캐시를 늘리고 누락된 범위를 가져와 캐시할 수 없는 이유는 무엇입니까? 이것이 문제를 해결할 것 같습니다. 결국 막대/틱을 요청할 때 데이터가 포함된 누락된 패킷이 반환되므로 이러한 메커니즘이 있습니다.
전체 기록이 다시 요청될 때 터미널이 캐시를 늘리고 누락된 범위를 가져와 캐시할 수 없는 이유는 무엇입니까?
이미 완료되었습니다.
그러나 HistorySelect( other_time, ... )가 HistorySelect( 0, INT_MAX ) 호출 사이에 호출되면 캐시가 other_time부터 다시 작성되고 다음 HistorySelect( 0, ... ) 요청으로 인해 캐시가 다시 작성됩니다( 더 느림).
이미 완료되었습니다.
그러나 HistorySelect( other_time, ... )가 HistorySelect( 0, INT_MAX ) 호출 사이에 호출되면 캐시가 other_time부터 다시 작성되고 다음 HistorySelect( 0, ... ) 요청으로 인해 캐시가 다시 작성됩니다( 더 느림).
그렇다면 좋은 것입니다. 유일한 질문은 캐시의 증가에 따라 수신된 데이터 작업의 편의성입니다.
거래 조작을 그렇게 깊이 이해하지 못했는데 요청 범위가 변경되면 전체 열거 없이 히스토리 내 데이터를 빠르게 검색할 가능성이 없다는 의미입니까?
거래 조작을 그렇게 깊이 이해하지 못했는데 요청 범위가 변경되면 전체 열거 없이 히스토리 내 데이터를 빠르게 검색할 가능성이 없다는 의미입니까?
이 지식을 사용하지 않는다면 왜 사용합니까?
실제 작업 없음 = 질문 없음.
OrderExist 및 PositionExist는 기호, 작업 유형 및 마법으로 레코드를 검색할 때 모든 주문 또는 위치의 루프에서 어리석은 반복을 피할 수 있도록 하는 특별히 최적화된 기능입니다.
결과적으로 티켓이 있는 배열을 얻습니다.
프로그램은 이러한 기능을 사용하여 많은 비용을 절약할 수 있습니다. 특히 그들이 열거 주기에서 열린 위치와 주문에 대규모로 지속적으로 반복적으로 액세스할 때.
앞으로 대규모 거래 데이터에 접근하기 위한 보다 효율적인 기능을 구현할 것입니다.
언어는 또한 더 강력한 기능으로 크게 증가하고 단순화할 것입니다.
" OrderExist 및 PositionExist" - 문서에서 찾지 못했습니다. 어디에서 읽을 수 있습니까?
가장 가능성 있음 - 다음 릴리스 버전(현재 베타) 릴리스 이후