문제는 TF를 전환할 때 터미널의 메모리가 해제되지 않는다는 것입니다. 작업 관리자 를 실행하고 차트에 표시기를 놓고 메모리가 증가하는 것을 지켜보십시오. Peter는 다른 TF로 전환합니다. 당신은 기억이 어떻게 다시 자라기 시작하는지 보게 될 것입니다. 논리적으로 다른 TF로 전환할 때 이전 TF의 데이터를 메모리에서 언로드해야 합니다. 이전 TF의 데이터는 파괴되지 않기 때문에 메모리가 과부하되어 오류가 발생할 때까지 메모리가 증가합니다. 차트에서 지표를 제거하면 일정 시간이 지나면 메모리가 지워지는 것을 볼 수 있습니다. 그러나 표시기가 실행되는 동안에는 지워지지 않습니다.
내 의견: 이 문제에 대한 해결책은 ServiceDec입니다.
감사합니다. 먼저 TF를 전환하기 전에 표시기를 제거하겠습니다. 또한 창의 최대 막대 수를 2000000에서 1000000으로 줄였습니다 .나에게 말하고 싶어.
pusheax : 네, 감사합니다. 메모리에 문제가 없도록 더욱 정리하겠습니다. 그렇지 않으면 InstaForex에서 108쌍을 사용하겠습니다.
Vapche 테마는 여전히 동일합니다. MT5의 새벽에도 모든 지표에 새로운 표준 매개변수, 즉 계산을 위한 막대 수를 도입해야 한다고 소리쳤습니다.
그렇지 않으면 단일 리미터( TERMINAL_MAXBARS )를 얻습니다. 이것은 지표를 사용하여 실시간으로 많은 도구를 분석하는 전문가에게는 허용되지 않습니다. 나는 가장 자주(99%) Expert Advisors AND ALL에 있는 마지막 막대의 특정 수를 엄격하게 지정해야 합니다. 다른 모든 것은 내 목구멍에 있습니다. 물론 저 뿐만 아니라...
무시되었습니다. 결과적으로 이러한 계산은 Expert Advisor의 코드로 전송됩니다.
아, 네! 그리고 많은 자체 작성 패치의 등장. 다음과 같은 스마트 기사도 작성 및 게시됩니다.
Renat : Индикаторы на короткой истории нельзя рассчитывать, так как они являются общим разделяющимся между всеми процессами (терминал, окна, эксперты) ресурсом. Причем на индикаторах действуют множество правил обновления, синхронизации и пересчета рыночного окружения.
Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
일반적으로 아무것도 변경되지 않습니다. MQL5를 사용하여 표시기 버퍼의 크기를 제한하는 기능을 도입하라는 요청은 거부되며, 사용된 표시기 버퍼가 많기 때문에 프로그램이 엄청난 양의 메모리를 사용하기 시작하면 이를 즉시 "프로그래머의 실수"라고 합니다.
"Expert Advisors에서 나는 가장 자주(99%) 마지막 마디 와 모든 것을 엄격하게 특정 수만큼 필요로 합니다. 불필요한 모든 것은 목구멍에 있습니다. 물론, 저 뿐만 아니라..." (c)
Renat : 2. 짧은 이력에 대한 지표는 모든 프로세스(터미널, 창, 전문가) 간에 공유되는 공통 자원이므로 계산할 수 없습니다. 또한 지표에 대한 시장 환경을 업데이트, 동기화 및 재계산하기 위한 많은 규칙이 있습니다.
3. 일반 표시 지표와 단기 계산 지표를 분리하면 긴 누적 지표에서 불일치가 발생하기 쉽습니다.
그것은 또한 우리 편에 위험한 목발로 이어질 것입니다.
1. 좋은 방법은 차트당 100000개의 막대를 설정하거나 x64로 전환하는 것입니다.
1. 그냥 그랬어요. 그래도 불편한 타협이다. 이상적으로는 개발의 문제를 완전히 무시한다면(순전히 사용자로서) 계산의 길이를 설정할 때 선택권을 갖고 싶습니다. 차트의 경우 - 전체 길이( 항상 그런 것은 아니지만 심각하고 상당한 예외가 있음), 전문가의 경우 - 필요한 만큼.
2. 생각해봅시다. 개발자로서 복잡성과 한계를 동시에 이해합니다. 그러한 접근 방식(계산 길이 표시 포함), 그러나 메모리 소비도 내 문제이며 그녀는 완고하게 보조 역할로 후퇴하기를 원하지 않습니다. 청구 기간을 고려하기 위한 특정 제안 솔루션 이 있습니다 . 그러면 매개변수가 모두 같지만 계산 기간이 다른 두 개의 지표는 단지 두 개의 다른 지표일 뿐입니다. 예, 이론적으로 추가 비용을 초래할 수 있는 어리석은 사용 사례가 있지만(사용자가 청구 기간을 연장하는 경우) 실제로는 그렇지 않습니다. 누군가가 이 갈퀴를 걷고 싶어한다면 그것은 그 자신의 잘못입니다. 대략 지금부터 모든 사용자는 "너무 많은 지표를 열고 TERMINAL_MAXBARS를 줄이는 데 신경 쓰지 않는" 책임이 있습니다.
3. 알아요 . 예를 들어 EMA를 계산할 때 시작 부분의 모든 막대가 사용된다는 것을 알고 있습니다. 그러나 확률론, RSI 및 기타 수많은 지표에서 제한된 길이로 계산이 이루어진다는 것도 알고 있습니다. 그리고 이 지식 을 통해 청구 기간(MaxBar) 선택에 유연하게 접근할 수 있습니다. 나에게 선택권을 주세요.
1. 그냥 그랬어요. 그래도 불편한 타협이다. 이상적으로는 개발의 문제를 완전히 무시한다면(순전히 사용자로서) 계산의 길이를 설정할 때 선택권을 갖고 싶습니다. 차트의 경우 - 전체 길이( 항상 그런 것은 아니지만 심각하고 상당한 예외가 있음), 전문가의 경우 - 필요한 만큼.
2. 생각해보자. 개발자로서 복잡성과 한계를 동시에 이해합니다. 그러한 접근 방식(계산 길이 표시 포함), 그러나 메모리 소비도 내 문제이며 그녀는 완고하게 보조 역할로 후퇴하기를 원하지 않습니다. 청구 기간을 고려하기 위한 특정 제안 솔루션 이 있습니다 . 그러면 매개변수가 모두 같지만 계산 기간이 다른 두 개의 지표는 단지 두 개의 다른 지표일 뿐입니다. 예, 이론적으로 추가 비용을 초래할 수 있는 어리석은 사용 사례가 있지만(사용자가 청구 기간을 연장하는 경우) 실제로는 그렇지 않습니다. 누군가가이 갈퀴를 걷고 싶어한다면 - 그것은 자신의 잘못입니다. 대략 지금부터 모든 사용자는 "너무 많은 지표를 열고 TERMINAL_MAXBARS 감소를 돌보지 않는" 책임이 있습니다.
3. 알아요 . 예를 들어 EMA를 계산할 때 시작 부분의 모든 막대가 사용된다는 것을 알고 있습니다. 그러나 나는 또한 확률론, RSI 및 수많은 다른 지표에서 제한된 길이로 계산이 이루어진다는 것을 알고 있습니다. 그리고 이 지식 을 통해 청구 기간(MaxBar) 선택에 유연하게 접근할 수 있습니다. 나에게 선택권을 주세요.
아이디어는 명확합니다.
우리는 자원 소비를 줄이기를 원합니다. 아마도 솔루션은 이 Expert Advisor에서 생성된 지표 에만 작용 하는 일부 함수 IndicatorMaxDepth(uint len)일 수 있습니다.
그러나 문제는 테스트 중에 누적 모드의 표시기 버퍼가 이력과 함께 증가하고 절약이 작동하지 않는다는 것입니다. 주어진 깊이를 유지하면서 지표의 기록을 실시간으로 트리밍하는 것은 차트 막대와 지표 버퍼의 동기화를 고려/익숙한 프로그래머를 위해 아름다운 결함과 지붕의 직접적인 철거로 가득 차 있습니다.
더 정확한 옵션은 x64로 전환하는 것입니다.
이제 최대 효율성의 원리와 메모리 절약의 원리를 비교한 표시기 캐시를 수정합니다. 버려진 지표를 언로드하고 지금처럼 한동안 메모리에 보관하지 않도록 합시다. 이를 통해 IndicatorRelease를 통한 직접 업로드로 수백 개의 지표를 연속으로 호출할 수 있습니다.
물론 누군가 언로드하지 않고 마켓 스캐닝 모드에서 수백 개의 지표를 호출하면 64비트 버전 + 추가 메모리 설치로만 직접 갈 수 있습니다.
이제 x32에서 대규모 테스트를 수행하는 것이 이상합니다. 16GB의 메모리가 있는 괜찮은 x64 컴퓨터(비디오 카드 및 모니터에 대한 열광적 없음)는 15,000루블에 구입할 수 있습니다.
창문에 있는 막대는 얼마입니까?
문제는 TF를 전환할 때 터미널의 메모리가 해제되지 않는다는 것입니다. 작업 관리자 를 실행하고 차트에 표시기를 놓고 메모리가 증가하는 것을 지켜보십시오. Peter는 다른 TF로 전환합니다. 당신은 기억이 어떻게 다시 자라기 시작하는지 보게 될 것입니다. 논리적으로 다른 TF로 전환할 때 이전 TF의 데이터를 메모리에서 언로드해야 합니다. 이전 TF의 데이터는 파괴되지 않기 때문에 메모리가 과부하되어 오류가 발생할 때까지 메모리가 증가합니다. 차트에서 지표를 제거하면 일정 시간이 지나면 메모리가 지워지는 것을 볼 수 있습니다. 그러나 표시기가 실행되는 동안에는 지워지지 않습니다.
내 의견: 이 문제에 대한 해결책은 ServiceDec입니다.
감사합니다. 먼저 TF를 전환하기 전에 표시기를 제거하겠습니다. 또한 창의 최대 막대 수를 2000000에서 1000000으로 줄였습니다 . 나에게 말하고 싶어.
그것이 작동하는 것처럼 보이는 동안.
감사합니다. 먼저 TF를 전환하기 전에 표시기를 제거하겠습니다. 또한 창의 최대 막대 수를 2000000에서 1000000으로 줄였습니다 . 나에게 말하고 싶어.
그것이 작동하는 것처럼 보이는 동안.
왜 만화가 필요한가요?? 100,000(십만)이면 충분합니다. 그것이 내가 암시했던 것입니다.
이것은 어떤 식으로든 테스트를 어떤 깊이로 제한하지 않습니다.
이것은 (1) 표시기 버퍼의 크기 (2) 창에서의 표시만을 제한합니다.
나는 오랫동안 의식적으로 "보이는 역사"를 제한했습니다. 결과 - 기억력에 문제가 없습니다.
왜 만화가 필요한가요?? 100,000(십만)이면 충분합니다. 그것이 내가 암시했던 것입니다.
이것은 어떤 식으로든 테스트를 어떤 깊이로 제한하지 않습니다.
이는 (1) 표시기 버퍼의 크기 (2) 창에 표시되는 것만 제한합니다.
나는 오랫동안 의식적으로 "보이는 역사"를 제한했습니다. 결과 - 기억력에 문제가 없습니다.
네, 감사합니다. 메모리에 문제가 없도록 더욱 정리하겠습니다. 그렇지 않으면 InstaForex에서 108쌍을 사용하겠습니다.
Vapche 테마는 여전히 동일합니다. MT5의 새벽에도 모든 지표에 새로운 표준 매개변수, 즉 계산을 위한 막대 수를 도입해야 한다고 소리쳤습니다.
그렇지 않으면 단일 리미터( TERMINAL_MAXBARS )를 얻습니다. 이것은 지표를 사용하여 실시간으로 많은 도구를 분석하는 전문가에게는 허용되지 않습니다. 나는 가장 자주(99%) Expert Advisors AND ALL에 있는 마지막 막대의 특정 수를 엄격하게 지정해야 합니다. 다른 모든 것은 내 목구멍에 있습니다. 물론 저 뿐만 아니라...
무시되었습니다. 결과적으로 이러한 계산은 Expert Advisor의 코드로 전송됩니다.
아, 네! 그리고 많은 자체 작성 패치의 등장. 다음과 같은 스마트 기사도 작성 및 게시됩니다.
보조 표시기의 메모리 소비 감소
Zigzag 및 ATR의 예에 대한 클래스로 지표 구현
...
일반 표시 지표와 단기 계산 지표를 분리하면 긴 누적 지표에서 불일치가 발생하기 쉽습니다.
그것은 또한 우리 편에 위험한 목발로 이어질 것입니다.
좋은 방법은 차트당 100000개의 막대를 설정하거나 x64로 전환하는 것입니다.
Renat :
Индикаторы на короткой истории нельзя рассчитывать, так как они являются общим разделяющимся между всеми процессами (терминал, окна, эксперты) ресурсом. Причем на индикаторах действуют множество правил обновления, синхронизации и пересчета рыночного окружения.
Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
일반적으로 아무것도 변경되지 않습니다. MQL5를 사용하여 표시기 버퍼의 크기를 제한하는 기능을 도입하라는 요청은 거부되며, 사용된 표시기 버퍼가 많기 때문에 프로그램이 엄청난 양의 메모리를 사용하기 시작하면 이를 즉시 "프로그래머의 실수"라고 합니다.
"Expert Advisors에서 나는 가장 자주(99%) 마지막 마디 와 모든 것을 엄격하게 특정 수만큼 필요로 합니다. 불필요한 모든 것은 목구멍에 있습니다. 물론, 저 뿐만 아니라..." (c)
2. 짧은 이력에 대한 지표는 모든 프로세스(터미널, 창, 전문가) 간에 공유되는 공통 자원이므로 계산할 수 없습니다. 또한 지표에 대한 시장 환경을 업데이트, 동기화 및 재계산하기 위한 많은 규칙이 있습니다.
3. 일반 표시 지표와 단기 계산 지표를 분리하면 긴 누적 지표에서 불일치가 발생하기 쉽습니다.
그것은 또한 우리 편에 위험한 목발로 이어질 것입니다.
1. 좋은 방법은 차트당 100000개의 막대를 설정하거나 x64로 전환하는 것입니다.
1. 그냥 그랬어요. 그래도 불편한 타협이다. 이상적으로는 개발의 문제를 완전히 무시한다면(순전히 사용자로서) 계산의 길이를 설정할 때 선택권을 갖고 싶습니다. 차트의 경우 - 전체 길이( 항상 그런 것은 아니지만 심각하고 상당한 예외가 있음), 전문가의 경우 - 필요한 만큼.
2. 생각해봅시다. 개발자로서 복잡성과 한계를 동시에 이해합니다. 그러한 접근 방식(계산 길이 표시 포함), 그러나 메모리 소비도 내 문제이며 그녀는 완고하게 보조 역할로 후퇴하기를 원하지 않습니다. 청구 기간을 고려하기 위한 특정 제안 솔루션 이 있습니다 . 그러면 매개변수가 모두 같지만 계산 기간이 다른 두 개의 지표는 단지 두 개의 다른 지표일 뿐입니다. 예, 이론적으로 추가 비용을 초래할 수 있는 어리석은 사용 사례가 있지만(사용자가 청구 기간을 연장하는 경우) 실제로는 그렇지 않습니다. 누군가가 이 갈퀴를 걷고 싶어한다면 그것은 그 자신의 잘못입니다. 대략 지금부터 모든 사용자는 "너무 많은 지표를 열고 TERMINAL_MAXBARS를 줄이는 데 신경 쓰지 않는" 책임이 있습니다.
3. 알아요 . 예를 들어 EMA를 계산할 때 시작 부분의 모든 막대가 사용된다는 것을 알고 있습니다. 그러나 확률론, RSI 및 기타 수많은 지표에서 제한된 길이로 계산이 이루어진다는 것도 알고 있습니다. 그리고 이 지식 을 통해 청구 기간(MaxBar) 선택에 유연하게 접근할 수 있습니다. 나에게 선택권을 주세요.
대략 지금부터 모든 사용자는 "너무 많은 지표를 열고 TERMINAL_MAXBARS를 줄이는 데 신경 쓰지 않는" 책임이 있습니다.
예, 특히 챔피언십 조건에서 TERMINAL_MAXBARS의 크기에 전혀 영향을 줄 수 없을 때.
1. 그냥 그랬어요. 그래도 불편한 타협이다. 이상적으로는 개발의 문제를 완전히 무시한다면(순전히 사용자로서) 계산의 길이를 설정할 때 선택권을 갖고 싶습니다. 차트의 경우 - 전체 길이( 항상 그런 것은 아니지만 심각하고 상당한 예외가 있음), 전문가의 경우 - 필요한 만큼.
2. 생각해보자. 개발자로서 복잡성과 한계를 동시에 이해합니다. 그러한 접근 방식(계산 길이 표시 포함), 그러나 메모리 소비도 내 문제이며 그녀는 완고하게 보조 역할로 후퇴하기를 원하지 않습니다. 청구 기간을 고려하기 위한 특정 제안 솔루션 이 있습니다 . 그러면 매개변수가 모두 같지만 계산 기간이 다른 두 개의 지표는 단지 두 개의 다른 지표일 뿐입니다. 예, 이론적으로 추가 비용을 초래할 수 있는 어리석은 사용 사례가 있지만(사용자가 청구 기간을 연장하는 경우) 실제로는 그렇지 않습니다. 누군가가이 갈퀴를 걷고 싶어한다면 - 그것은 자신의 잘못입니다. 대략 지금부터 모든 사용자는 "너무 많은 지표를 열고 TERMINAL_MAXBARS 감소를 돌보지 않는" 책임이 있습니다.
3. 알아요 . 예를 들어 EMA를 계산할 때 시작 부분의 모든 막대가 사용된다는 것을 알고 있습니다. 그러나 나는 또한 확률론, RSI 및 수많은 다른 지표에서 제한된 길이로 계산이 이루어진다는 것을 알고 있습니다. 그리고 이 지식 을 통해 청구 기간(MaxBar) 선택에 유연하게 접근할 수 있습니다. 나에게 선택권을 주세요.
아이디어는 명확합니다.
우리는 자원 소비를 줄이기를 원합니다. 아마도 솔루션은 이 Expert Advisor에서 생성된 지표 에만 작용 하는 일부 함수 IndicatorMaxDepth(uint len)일 수 있습니다.
그러나 문제는 테스트 중에 누적 모드의 표시기 버퍼가 이력과 함께 증가하고 절약이 작동하지 않는다는 것입니다. 주어진 깊이를 유지하면서 지표의 기록을 실시간으로 트리밍하는 것은 차트 막대와 지표 버퍼의 동기화를 고려/익숙한 프로그래머를 위해 아름다운 결함과 지붕의 직접적인 철거로 가득 차 있습니다.
더 정확한 옵션은 x64로 전환하는 것입니다.
이제 최대 효율성의 원리와 메모리 절약의 원리를 비교한 표시기 캐시를 수정합니다. 버려진 지표를 언로드하고 지금처럼 한동안 메모리에 보관하지 않도록 합시다. 이를 통해 IndicatorRelease를 통한 직접 업로드로 수백 개의 지표를 연속으로 호출할 수 있습니다.
물론 누군가 언로드하지 않고 마켓 스캐닝 모드에서 수백 개의 지표를 호출하면 64비트 버전 + 추가 메모리 설치로만 직접 갈 수 있습니다.
이제 x32에서 대규모 테스트를 수행하는 것이 이상합니다. 16GB의 메모리가 있는 괜찮은 x64 컴퓨터(비디오 카드 및 모니터에 대한 열광적 없음)는 15,000루블에 구입할 수 있습니다.