차트에서 특성을 제거하기 위해 차트에 명령이 필요한 이유는 무엇입니까? 메모리에 있는 모든 차트의 특성에 대한 테이블만 있으면 밀리초가 아닌 나노초 단위로 데이터를 읽을 수 있습니다(마이크로초도 아닙니다!). ChartSetInteger, ChartSetDouble, ChartSetString 함수는 비동기식임이 분명합니다. 그런데 왜 ChartGetInteger , ChartGetDouble , ChartGetString 함수 는 동기적이지만 실행 속도 측면에서 비동기식으로 동작합니까?
그러한 테이블이 메모리에 존재하지 않고 이러한 함수가 요청된 매개변수를 생성하기 위해 매번 차트의 속도를 늦춰야 하는 경우, 저는 아무 것도 이해할 수 없습니다. 결국, 그러한 테이블을 보유하고 최신 상태로 유지하는 것은 전혀 비용이 들지 않습니다. 현실적으로 차트의 특성을 변경할 때 테이블을 업데이트하는 데 몇 킬로바이트의 메모리와 마이크로초의 작은 부분이 필요합니다. Ilyas, 내가 이해하지 못하는 것을 말해주세요?
그러나 왜 ChartGetInteger, ChartGetDouble, ChartGetString 함수는 동기식일 때 실행 속도 측면에서 비동기식으로 동작합니까?
비동기 및 동기라는 용어를 잘못 이해하고 있습니다. 함수가 비동기식이라는 것은 현재 실행 스레드가 아니라 다른 병렬 스레드에서 실행된다는 의미입니다.
함수는 비동기식입니다. 즉, 함수는 지정된 차트에 성공적으로 대기 중인 명령의 실행을 기다리지 않고 즉시 제어를 반환합니다. 속성은 차트 대기열에서 명령이 처리된 후에만 변경됩니다. 차트 대기열에서 즉시 명령을 실행하려면ChartRedraw 함수를 호출하십시오 .
메인 스레드에서 비동기 ChartSetInteger 함수를 호출하는 것은 실제 실행이 다른 스레드에서 발생하기 때문에 빠릅니다.
반면에 동기 함수 ChartGetInteger를 호출하려면 스레드 동기화가 필요하며 추가 시간이 걸릴 수 있습니다. 지연은 병렬 스레드가 차트 구조의 데이터를 지속적으로 업데이트할 때(예: 사용자가 차트 창을 이동하거나 기록을 스크롤할 때) 특히 두드러집니다. 단순성과 신뢰성을 위해 차트 데이터 구조에 하나의 동기화 개체가 사용됩니다. "데이터 분할"을 사용하여 실행 속도를 개선할 수 있지만 다른 한편으로는 이제 교착 상태에 빠지거나 데이터가 제대로 업데이트되지 않거나 다른 중요한 위치에서 속도가 느려질 가능성이 있습니다. 일반적으로 이미 안정적으로 작동하는 것을 만지지 않는 것이 좋습니다.
비동기 및 동기라는 용어를 잘못 이해하고 있습니다. 함수가 비동기식이라는 것은 현재 실행 스레드가 아니라 다른 병렬 스레드에서 실행된다는 의미입니다.
메인 스레드에서 비동기 ChartSetInteger 함수를 호출하는 것은 실제 실행이 다른 스레드에서 발생하기 때문에 빠릅니다.
반면에 동기 함수 ChartGetInteger를 호출하려면 스레드 동기화가 필요하며 추가 시간이 걸릴 수 있습니다. 지연은 병렬 스레드가 차트 구조의 데이터를 지속적으로 업데이트할 때(예: 사용자가 차트 창을 이동하거나 기록을 스크롤할 때) 특히 두드러집니다. 단순성과 신뢰성을 위해 차트 데이터 구조에 하나의 동기화 개체가 사용됩니다. "데이터 분할"을 사용하여 실행 속도를 개선할 수 있지만 다른 한편으로는 이제 교착 상태에 빠지거나 데이터가 제대로 업데이트되지 않거나 다른 중요한 위치에서 속도가 느려질 가능성이 있습니다. 일반적으로 이미 안정적으로 작동하는 것을 만지지 않는 것이 좋습니다.
맞습니다. 하지만 약간의 병목 현상이 있는 것 같습니다. 이제 시장이 닫혔습니다. 1개의 차트에서 아래 코드를 실행했는데 다른 것은 작동하지 않습니다. MT5만 작동 하는 VPS에서 실행 중이며 스크린샷을 찍는 것 외에는 차트/MT5와 상호 작용하지 않았습니다. 시간(µs)은 평균 127µs이지만 피크는 43,995µs입니다.
잘못된 스레드에 게시한 경우 수정하십시오. 사용과 디버깅의 용이성을 위한 제안이 있으며, 이는 많은 사람들에게 유용할 것이라고 생각하지만 저에게는 중요합니다.
1. 개체에 대한 OBJPROP_TOOLTIP 문자열의 길이를 늘립니다(2번이면 충분). 그래픽이 많은 전략의 경우 현재 길이가 매우 작습니다. 디버깅을 위해 필요한 모든 데이터를 맞추는 데 시간을 할애해야 할 때마다. 그런 다음 정기적으로 변경하고(또는) 소비자를 위한 약어를 추가합니다.
2. 주석의 길이를 입력 매개변수의 이름으로 늘립니다(2번이면 충분합니다). 소비자는 입력 매개변수에 대한 설명이 필요합니다. 그리고 숫자가 많으면 추가로 번호를 매기기에도 편리합니다. 최적화를 위해서는 변수의 이름을 아는 것이 중요합니다. 결과적으로 현재 길이에 모든 것을 맞추는 것은 종종 불가능합니다. 예시:
3. 최적화 결과 테이블의 열 선택을 다양화합니다. ENUM_STATISTICS에서 모든 것을 제거할 때까지 사용자는 이미 필요한 것을 선택합니다. 글쎄요, 분석을 위한 아주 나쁜 선택입니다. 고정 볼륨으로 최적화할 때 %의 드로다운은 쓸모가 없습니다. 자금 및 예금에 대한 통화의 최대 인출은 선택할 수 없습니다. 때때로 최적화 중에 매수 포지션과 매도 포지션 사이에 강한 편향이 있지만, 단일 테스트를 실행한 후에야 알 수 있습니다. 결과 필드( STAT_CUSTOM_ONTESTER )에 누락된 매개변수를 남겨두어야 하는 경우가 많습니다. 하지만 거기에 추가 결과 기준을 표시하고 싶고 하나만 표시할 수 있습니다. ENUM_STATISTICS의 표준 기준 열 수가 변하는 경우에도 여전히 참을 수 있습니다. 일반적으로 재최적화 및 분석에 많은 추가 시간을 소비해야 합니다.
맞습니다. 하지만 약간의 병목 현상이 있는 것 같습니다. 이제 시장이 닫혔습니다. 1개의 차트에서 아래 코드를 실행했는데 다른 것은 작동하지 않습니다. MT5만 작동 하는 VPS에서 실행 중이며 스크린샷을 찍는 것 외에는 차트/MT5와 상호 작용하지 않았습니다. 시간(µs)은 평균 127µs이지만 피크는 43,995µs입니다.
피크가 차트 주석의 그림이라고 가정합니다. 그렇지 않으면 차트 대기열이 비어 있을 때 ChartGetXXX 함수 호출(동기화 호출)에 0.13밀리초가 걸립니다.
비동기 및 동기라는 용어를 잘못 이해하고 있습니다. 함수가 비동기식이라는 것은 현재 실행 스레드가 아니라 다른 병렬 스레드에서 실행된다는 의미입니다.
메인 스레드에서 비동기 ChartSetInteger 함수를 호출하는 것은 실제 실행이 다른 스레드에서 발생하기 때문에 빠릅니다.
반면에 동기 함수 ChartGetInteger를 호출하려면 스레드 동기화가 필요하며 추가 시간이 걸릴 수 있습니다. 지연은 병렬 스레드가 차트 구조의 데이터를 지속적으로 업데이트할 때(예: 사용자가 차트 창을 이동하거나 기록을 스크롤할 때) 특히 두드러집니다. 단순성과 신뢰성을 위해 차트 데이터 구조에 하나의 동기화 개체가 사용됩니다. "데이터 분할"을 사용하여 실행 속도를 개선할 수 있지만 다른 한편으로는 이제 교착 상태에 빠지거나 데이터가 제대로 업데이트되지 않거나 다른 중요한 위치에서 속도가 느려질 가능성이 있습니다. 일반적으로 이미 안정적으로 작동하는 것을 만지지 않는 것이 좋습니다.
맞습니다. 동기 명령의 처리 속도를 높이려면 아키텍처의 변경(특히 GUI)이 필요합니다. 더 많은 로드/시간을 제공하여 차트 렌더링을 차단하는 것은 바로 그 사람입니다.
Признак отрисовки ценового графика. Если установлено значение false, то отключается отрисовка любых атрибутов ценового графика и устраняются все отступы по краям графика: шкалы времени и цены, строка быстрой навигации, метки событий Календаря, значки сделок, тултипы индикаторов и баров, подокна индикаторов, гистограммы объёмов и т.д. Значение...
이것은 실수가 아닙니다. 이것은 차트에 대한 동기 명령의 비용입니다.
차트에서 특성을 제거하기 위해 차트에 명령이 필요한 이유는 무엇입니까? 메모리에 있는 모든 차트의 특성에 대한 테이블만 있으면 밀리초가 아닌 나노초 단위로 데이터를 읽을 수 있습니다(마이크로초도 아닙니다!).
ChartSetInteger, ChartSetDouble, ChartSetString 함수는 비동기식임이 분명합니다.
그런데 왜 ChartGetInteger , ChartGetDouble , ChartGetString 함수 는 동기적이지만 실행 속도 측면에서 비동기식으로 동작합니까?
그러한 테이블이 메모리에 존재하지 않고 이러한 함수가 요청된 매개변수를 생성하기 위해 매번 차트의 속도를 늦춰야 하는 경우, 저는 아무 것도 이해할 수 없습니다.
결국, 그러한 테이블을 보유하고 최신 상태로 유지하는 것은 전혀 비용이 들지 않습니다. 현실적으로 차트의 특성을 변경할 때 테이블을 업데이트하는 데 몇 킬로바이트의 메모리와 마이크로초의 작은 부분이 필요합니다.
Ilyas, 내가 이해하지 못하는 것을 말해주세요?
그러나 왜 ChartGetInteger, ChartGetDouble, ChartGetString 함수는 동기식일 때 실행 속도 측면에서 비동기식으로 동작합니까?
비동기 및 동기라는 용어를 잘못 이해하고 있습니다.
함수가 비동기식이라는 것은 현재 실행 스레드가 아니라 다른 병렬 스레드에서 실행된다는 의미입니다.
함수는 비동기식입니다. 즉, 함수는 지정된 차트에 성공적으로 대기 중인 명령의 실행을 기다리지 않고 즉시 제어를 반환합니다.
속성은 차트 대기열에서 명령이 처리된 후에만 변경됩니다. 차트 대기열에서 즉시 명령을 실행하려면 ChartRedraw 함수를 호출하십시오 .
메인 스레드에서 비동기 ChartSetInteger 함수를 호출하는 것은 실제 실행이 다른 스레드에서 발생하기 때문에 빠릅니다.
반면에 동기 함수 ChartGetInteger를 호출하려면 스레드 동기화가 필요하며 추가 시간이 걸릴 수 있습니다.
지연은 병렬 스레드가 차트 구조의 데이터를 지속적으로 업데이트할 때(예: 사용자가 차트 창을 이동하거나 기록을 스크롤할 때) 특히 두드러집니다.
단순성과 신뢰성을 위해 차트 데이터 구조에 하나의 동기화 개체가 사용됩니다.
"데이터 분할"을 사용하여 실행 속도를 개선할 수 있지만 다른 한편으로는 이제 교착 상태에 빠지거나 데이터가 제대로 업데이트되지 않거나 다른 중요한 위치에서 속도가 느려질 가능성이 있습니다.
일반적으로 이미 안정적으로 작동하는 것을 만지지 않는 것이 좋습니다.
비동기 및 동기라는 용어를 잘못 이해하고 있습니다.
함수가 비동기식이라는 것은 현재 실행 스레드가 아니라 다른 병렬 스레드에서 실행된다는 의미입니다.
메인 스레드에서 비동기 ChartSetInteger 함수를 호출하는 것은 실제 실행이 다른 스레드에서 발생하기 때문에 빠릅니다.
반면에 동기 함수 ChartGetInteger를 호출하려면 스레드 동기화가 필요하며 추가 시간이 걸릴 수 있습니다.
지연은 병렬 스레드가 차트 구조의 데이터를 지속적으로 업데이트할 때(예: 사용자가 차트 창을 이동하거나 기록을 스크롤할 때) 특히 두드러집니다.
단순성과 신뢰성을 위해 차트 데이터 구조에 하나의 동기화 개체가 사용됩니다.
"데이터 분할"을 사용하여 실행 속도를 개선할 수 있지만 다른 한편으로는 이제 교착 상태에 빠지거나 데이터가 제대로 업데이트되지 않거나 다른 중요한 위치에서 속도가 느려질 가능성이 있습니다.
일반적으로 이미 안정적으로 작동하는 것을 만지지 않는 것이 좋습니다.
맞습니다. 하지만 약간의 병목 현상이 있는 것 같습니다. 이제 시장이 닫혔습니다. 1개의 차트에서 아래 코드를 실행했는데 다른 것은 작동하지 않습니다. MT5만 작동 하는 VPS에서 실행 중이며 스크린샷을 찍는 것 외에는 차트/MT5와 상호 작용하지 않았습니다. 시간(µs)은 평균 127µs이지만 피크는 43,995µs입니다.
개발자님!
잘못된 스레드에 게시한 경우 수정하십시오. 사용과 디버깅의 용이성을 위한 제안이 있으며, 이는 많은 사람들에게 유용할 것이라고 생각하지만 저에게는 중요합니다.
1. 개체에 대한 OBJPROP_TOOLTIP 문자열의 길이를 늘립니다(2번이면 충분). 그래픽이 많은 전략의 경우 현재 길이가 매우 작습니다. 디버깅을 위해 필요한 모든 데이터를 맞추는 데 시간을 할애해야 할 때마다. 그런 다음 정기적으로 변경하고(또는) 소비자를 위한 약어를 추가합니다.
2. 주석의 길이를 입력 매개변수의 이름으로 늘립니다(2번이면 충분합니다). 소비자는 입력 매개변수에 대한 설명이 필요합니다. 그리고 숫자가 많으면 추가로 번호를 매기기에도 편리합니다. 최적화를 위해서는 변수의 이름을 아는 것이 중요합니다. 결과적으로 현재 길이에 모든 것을 맞추는 것은 종종 불가능합니다. 예시:
3. 최적화 결과 테이블의 열 선택을 다양화합니다. ENUM_STATISTICS에서 모든 것을 제거할 때까지 사용자는 이미 필요한 것을 선택합니다. 글쎄요, 분석을 위한 아주 나쁜 선택입니다. 고정 볼륨으로 최적화할 때 %의 드로다운은 쓸모가 없습니다. 자금 및 예금에 대한 통화의 최대 인출은 선택할 수 없습니다. 때때로 최적화 중에 매수 포지션과 매도 포지션 사이에 강한 편향이 있지만, 단일 테스트를 실행한 후에야 알 수 있습니다. 결과 필드( STAT_CUSTOM_ONTESTER )에 누락된 매개변수를 남겨두어야 하는 경우가 많습니다. 하지만 거기에 추가 결과 기준을 표시하고 싶고 하나만 표시할 수 있습니다. ENUM_STATISTICS의 표준 기준 열 수가 변하는 경우에도 여전히 참을 수 있습니다. 일반적으로 재최적화 및 분석에 많은 추가 시간을 소비해야 합니다.
고맙습니다!
맞습니다. 하지만 약간의 병목 현상이 있는 것 같습니다. 이제 시장이 닫혔습니다. 1개의 차트에서 아래 코드를 실행했는데 다른 것은 작동하지 않습니다. MT5만 작동 하는 VPS에서 실행 중이며 스크린샷을 찍는 것 외에는 차트/MT5와 상호 작용하지 않았습니다. 시간(µs)은 평균 127µs이지만 피크는 43,995µs입니다.
피크가 차트 주석의 그림이라고 가정합니다. 그렇지 않으면 차트 대기열이 비어 있을 때 ChartGetXXX 함수 호출(동기화 호출)에 0.13밀리초가 걸립니다.
비동기 및 동기라는 용어를 잘못 이해하고 있습니다.
함수가 비동기식이라는 것은 현재 실행 스레드가 아니라 다른 병렬 스레드에서 실행된다는 의미입니다.
메인 스레드에서 비동기 ChartSetInteger 함수를 호출하는 것은 실제 실행이 다른 스레드에서 발생하기 때문에 빠릅니다.
반면에 동기 함수 ChartGetInteger를 호출하려면 스레드 동기화가 필요하며 추가 시간이 걸릴 수 있습니다.
지연은 병렬 스레드가 차트 구조의 데이터를 지속적으로 업데이트할 때(예: 사용자가 차트 창을 이동하거나 기록을 스크롤할 때) 특히 두드러집니다.
단순성과 신뢰성을 위해 차트 데이터 구조에 하나의 동기화 개체가 사용됩니다.
"데이터 분할"을 사용하여 실행 속도를 개선할 수 있지만 다른 한편으로는 이제 교착 상태에 빠지거나 데이터가 제대로 업데이트되지 않거나 다른 중요한 위치에서 속도가 느려질 가능성이 있습니다.
일반적으로 이미 안정적으로 작동하는 것을 만지지 않는 것이 좋습니다.
PrtScr 버튼을 누른 상태에서 차트 창을 원으로 이동하면 최대 5초 슬로우 모션으로 끔찍한 지연이 발생합니다.
그러나 ALT + PrtScr을 통해 terminal.exe 프로그램 창만 스크린샷하면 지연이 없습니다.
내장된 VPS 서비스 로 판단하면 이 문제에 대한 경험이 있습니다.
피크가 차트 주석의 렌더링이라고 가정합니다. 그렇지 않으면 차트 대기열이 비어 있을 때 ChartGetXXX 함수 호출(참고, 동기화 호출)에 0.13밀리초가 걸립니다.
아니요, Ilyas 는 차트에 댓글 이 없는 것 같습니다. 로그를 사용하여 게시합니다.
편집: 다음은 결과입니다. 시작 후 로그를 복사하는 것 외에는 차트 또는 MT5 또는 Windows와 상호 작용이 없습니다. 1개의 차트만 있고 시스템에서 다른 소프트웨어가 실행되고 있지 않습니다. 피크는 작지만 평균에 비해 여전히 매우 중요합니다. (μs)
2020.06.13 07:11:25.192 342152 (EURGBP, H1) 금액 = 7440
2020.06.13 07:11:25.192 342152 (EURGBP, H1) 최소=37
2020.06.13 07:11:25.192 342152 (EURGBP, H1) 최대 = 17776
2020.06.13 07:11:25.192 342152 (EURGBP, H1) 평균 = 147
아니요, Ilyas 는 차트에 댓글 이 없는 것 같습니다. 로그를 사용하여 게시합니다.
편집: 다음은 결과입니다. 시작 후 로그를 복사하는 것 외에는 차트 또는 MT5 또는 Windows와 상호 작용이 없습니다. 1개의 차트만 있고 시스템에서 다른 소프트웨어가 실행되고 있지 않습니다. 피크는 작지만 평균에 비해 여전히 매우 중요합니다. (μs)
2020.06.13 07:11:25.192 342152 (EURGBP, H1) 금액 = 7440
2020.06.13 07:11:25.192 342152 (EURGBP, H1) 최소=37
2020.06.13 07:11:25.192 342152 (EURGBP, H1) 최대 = 17776
2020.06.13 07:11:25.192 342152 (EURGBP, H1) 평균=147
업데이트 :
최대 피크가 이제 심각하게 증가합니다.
2020.06.13 08:18:25.187 342152 (EURGBP, H1) 금액 = 23520
2020.06.13 08:18:25.187 342152 (EURGBP, H1) 최소 = 33
2020.06.13 08:18:25.187 342152 (EURGBP, H1) 최대 = 81011
2020.06.13 08:18:25.187 342152 (EURGBP, H1) 평균 = 149