어-허, 귀하의 경우에 "기민함"이라는 개념만 매우 상대적입니다. 사용자가 막대 배열을 요청하는 것은 한 가지입니다. 메모리 조각이 단순히 그에게 복사되었습니다. 또는 특정 시계열을 요청한 경우 구조의 크기와 동일한 일정한 단계로 데이터의 간단한 복사도 있습니다. 그리고 또 다른 문제 - 각 숫자에 대한 추가 계산 및 변환.
개인적으로 나는 간결한 역사를 선호하지만 기억을 낭비하지 않기 때문입니다. 어쨌든, 나는 그것의 저장을 위해 내 자신의 배열을 구성합니다. 그래서 조금 기다리겠습니다. 그러나 대부분의 다른 사용자는 이것을 위해 당신을 조각으로 찢을 것입니다)
ps 비록 이상적으로는, 메모리에 히스토리를 저장하는 모드를 선택하기 위해 터미널에 그러한 옵션이 있으면 좋을 것입니다. 예를 들어 시스템에 RAM이 거의 없지만 프로세서는 빠른 경우 매우 유용합니다.
잘 봐. 방금 내 SDD에서 읽기 및 쓰기 속도를 측정했습니다. 쓰고 읽는 시간은 8바이트(1값 타입 double or datetime or long) ~ 48ns인 것으로 밝혀졌다. 내 계산에 따르면 묶음 배열에서 8바이트 정보를 읽는 데 걸리는 시간은 1-2ns입니다. 저것들. 구조 요소에 액세스할 때 1-2ns가 손실된다는 사실에도 불구하고 디스크에서 쓰고 읽을 때 48 * 0.8 = 38ns를 얻습니다. 동시에 RAM과 디스크 공간도 5배 절약합니다. HDD 정보는 일반적으로 조용합니다.
잘 봐. 방금 내 SDD에서 읽기 및 쓰기 속도를 측정했습니다. 8바이트(1 값 유형 double 또는 datetime 또는 long) 쓰기 및 읽기 시간은 48ns인 것으로 나타났습니다. 내 계산에 따르면 묶음 배열에서 8바이트 정보를 읽는 데 걸리는 시간은 1-2ns입니다. 저것들. 구조 요소에 액세스할 때 1-2ns가 손실된다는 사실에도 불구하고 디스크에서 쓰고 읽을 때 48 * 0.8 = 38ns를 얻습니다. 동시에 RAM과 디스크 공간도 5배 절약합니다. HDD 정보는 일반적으로 조용합니다.
이것으로 나는 논쟁하지 않습니다. 특히 디스크에서 데이터를 다운로드하는 경우에는 확실히 맞습니다. 우리는 4년 전 이 주제에 대해 Renat와 논쟁을 벌였습니다. 당시 SSD는 여전히 드물었고 대다수의 사용자는 느린 HDD에 앉아 있었습니다. 그래서 나는 (예를 들어 내 SSD를 사용하여) 그에게 하드 디스크 작업이 시스템에서 가장 제동이 걸리는 연결이며, 그 반대의 경우가 아니라 하드 디스크에서 소비되는 정보의 양을 최소화해야 한다고 설득하려고 했습니다. 그러나 그는 프로세서에 불필요한 작업을 로드할 필요가 없으며 일반적으로 여기에서 모두 바보이고 아무 것도 이해하지 못한다는 등의 주장을 했습니다. 일반적으로 모든 것이 평소와 같습니다)
사실, 현재 SSD는 눈에 띄게 가속화되었습니다.
쓰기 및 읽기 시간이 8바이트인 것으로 나타났습니다.
읽기와 함께 쓰는 이유는 무엇입니까? 말하자면, 데이터는 서버로부터 받은 즉시 또는 캐시를 생성할 때 한 번 작성되어야 합니다. 그리고 그냥 읽기만 하면 됩니다. 따라서 커틀릿은 별도로, 별도로 날아갑니다.
네, 아카이브입니다. 내가 올바르게 이해했다면 이제 디스크에 있는 것, 메모리에 있는 것, 눈금 및 분 막대가 압축되지 않은 형태로 저장됩니다. 막대( MqlRates 구조 )의 경우 60바이트이고 틱( MqlTick 구조 )의 경우 52바이트입니다. 공포! 이 문제에 대해 오랫동안 조치를 취해야 합니다.
압축된 배열의 주요 문제는 배열의 각 요소에 대한 빠른 액세스 구성이라는 것을 알고 있습니다.
그러나 압축을 푼 배열의 256번째 요소만 저장하고 다른 요소에 압축을 푼 요소의 증분만 저장하더라도 배열의 크기는 눈으로 보면 4-5배 줄어들고 각 요소에 대한 액세스 시간은 그다지 증가하지는 않지만(1-2나노초 정도) 디스크에서 디스크로 어레이를 저장하고 읽는 데 드는 시간을 크게 절약할 수 있습니다.
"모든 것은 이미 당신보다 먼저 도난당했습니다." (c)
하루가 시작될 때 - 전체 틱. 그런 다음 입찰 및/또는 요청 및/또는 완전히 마지막으로, 다른 모든 것은 증분입니다(있는 경우). 틱당 평균 10바이트입니다.
틱에 대한 액세스는 엄격하게 순차적이므로 배열의 각 요소에 대한 빠른 액세스를 구성하는 데 문제가 없습니다.
어-허, 귀하의 경우에 "기민함"이라는 개념만 매우 상대적입니다. 사용자가 막대 배열을 요청하는 것은 한 가지입니다. 메모리 조각이 단순히 그에게 복사되었습니다. 또는 특정 시계열을 요청한 경우 구조의 크기와 동일한 일정한 단계로 데이터의 간단한 복사도 있습니다. 그리고 또 다른 문제 - 각 숫자에 대한 추가 계산 및 변환.
개인적으로 나는 간결한 역사를 선호하지만 기억을 낭비하지 않기 때문입니다. 어쨌든, 나는 그것의 저장을 위해 내 자신의 배열을 구성합니다. 그래서 조금 기다리겠습니다. 그러나 대부분의 다른 사용자는 이것을 위해 당신을 조각으로 찢을 것입니다)
ps 비록 이상적으로는, 메모리에 히스토리를 저장하는 모드를 선택하기 위해 터미널에 그러한 옵션이 있으면 좋을 것입니다. 예를 들어 시스템에 RAM이 거의 없지만 프로세서는 빠른 경우 매우 유용합니다.
잘 봐. 방금 내 SDD에서 읽기 및 쓰기 속도를 측정했습니다. 쓰고 읽는 시간은 8바이트(1값 타입 double or datetime or long) ~ 48ns인 것으로 밝혀졌다. 내 계산에 따르면 묶음 배열에서 8바이트 정보를 읽는 데 걸리는 시간은 1-2ns입니다. 저것들. 구조 요소에 액세스할 때 1-2ns가 손실된다는 사실에도 불구하고 디스크에서 쓰고 읽을 때 48 * 0.8 = 38ns를 얻습니다. 동시에 RAM과 디스크 공간도 5배 절약합니다. HDD 정보는 일반적으로 조용합니다.
잘 봐. 방금 내 SDD에서 읽기 및 쓰기 속도를 측정했습니다. 8바이트(1 값 유형 double 또는 datetime 또는 long) 쓰기 및 읽기 시간은 48ns인 것으로 나타났습니다. 내 계산에 따르면 묶음 배열에서 8바이트 정보를 읽는 데 걸리는 시간은 1-2ns입니다. 저것들. 구조 요소에 액세스할 때 1-2ns가 손실된다는 사실에도 불구하고 디스크에서 쓰고 읽을 때 48 * 0.8 = 38ns를 얻습니다. 동시에 RAM과 디스크 공간도 5배 절약합니다. HDD 정보는 일반적으로 조용합니다.
이것으로 나는 논쟁하지 않습니다. 특히 디스크에서 데이터를 다운로드하는 경우에는 확실히 맞습니다. 우리는 4년 전 이 주제에 대해 Renat와 논쟁을 벌였습니다. 당시 SSD는 여전히 드물었고 대다수의 사용자는 느린 HDD에 앉아 있었습니다. 그래서 나는 (예를 들어 내 SSD를 사용하여) 그에게 하드 디스크 작업이 시스템에서 가장 제동이 걸리는 연결이며, 그 반대의 경우가 아니라 하드 디스크에서 소비되는 정보의 양을 최소화해야 한다고 설득하려고 했습니다. 그러나 그는 프로세서에 불필요한 작업을 로드할 필요가 없으며 일반적으로 여기에서 모두 바보이고 아무 것도 이해하지 못한다는 등의 주장을 했습니다. 일반적으로 모든 것이 평소와 같습니다)
사실, 현재 SSD는 눈에 띄게 가속화되었습니다.
쓰기 및 읽기 시간이 8바이트인 것으로 나타났습니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
오류, 버그, 질문
fxsaber , 2018.09.10 21:28
먼저 최적화 로그
Tester optimization finished, total passes 714240 Statistics optimization done in 7 hours 31 minutes 06 seconds Statistics local 714240 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%) Core 1 connection closed Core 2 connection closed Core 3 connection closed Core 4 connection closed Core 5 connection closed Core 6 connection closed Core 7 connection closed Core 8 connection closed Tester 714240 new records saved to cache file 'tester\cache\Test.FILTER_EURUSD.rann_RannForex.M1.20180226.20180909.40.2D734373DF0CAD251E2BD6535A4C6C84.opt'이 7.5시간 동안 SSD는 엄청난 빈도로 액세스되었습니다. 각 패스에서 틱을 읽으면 7.5시간 동안 초당 평균 26번으로 나타납니다. 따라서 그러한 야생 깜박임 - 700,000 개 이상의 판독 값.
단일 실행 로그
~130K 틱과 60K 막대가 사용되는 것을 볼 수 있습니다(테스터에서 "모든 기록" 모드가 선택됨). 저것들. 글쎄, 아주 약간의 역사.
터미널 자체에 있는 커스텀 심볼의 히스토리에는 너무 많은 히스토리 데이터가 포함되어 있습니다.
저것들. 기호의 역사에서 테스터가 사용하는 것보다 훨씬 많습니다.
위협 SSD를 보니 아쉽네요... 최적화 속도는 얼마나 더 높을 수 있을까요? OS가 이 데이터를 캐시하지 않는 것이 이상합니다. 압축되지 않은 형식으로 7M 틱 미만이기 때문입니다.
SSD가 아닌 메모리에서 데이터를 읽고 쓰려면 터미널의 어떤 폴더를 mklink를 통해 RAM 디스크에 넣어야 합니까? 데이터를 제공할 준비가 되었습니다. 최적화 중에 데이터가 제공할 가속도입니다.
네, 아카이브입니다. 내가 올바르게 이해했다면 이제 디스크에 있는 것, 메모리에 있는 것, 눈금 및 분 막대가 압축되지 않은 형태로 저장됩니다. 막대( MqlRates 구조 )의 경우 60바이트이고 틱( MqlTick 구조 )의 경우 52바이트입니다.
공포! 이 문제에 대해 오랫동안 조치를 취해야 합니다.
압축된 배열의 주요 문제는 배열의 각 요소에 대한 빠른 액세스 구성이라는 것을 알고 있습니다.
그러나 압축을 푼 배열의 256번째 요소만 저장하고 다른 요소에 압축을 푼 요소의 증분만 저장하더라도 배열의 크기는 눈으로 보면 4-5배 줄어들고 각 요소에 대한 액세스 시간은 그다지 증가하지는 않지만(1-2나노초 정도) 디스크에서 디스크로 어레이를 저장하고 읽는 데 드는 시간을 크게 절약할 수 있습니다.
"모든 것은 이미 당신보다 먼저 도난당했습니다." (c)
하루가 시작될 때 - 전체 틱. 그런 다음 입찰 및/또는 요청 및/또는 완전히 마지막으로, 다른 모든 것은 증분입니다(있는 경우). 틱당 평균 10바이트입니다.
틱에 대한 액세스는 엄격하게 순차적이므로 배열의 각 요소에 대한 빠른 액세스를 구성하는 데 문제가 없습니다.
"Tester\cache\*.opt" 항목의 출처를 게시해 주시기 바랍니다. 내용은 형식이 매우 간단함을 보여줍니다.
Optimization 의 결과 로 작업하는 것은 매우 필요합니다. 고맙습니다!
어떤 이유로 거래 횟수가 증가함에 따라 테스터의 성능이 떨어집니다. 동시에 고문 측에서는 거래 내역에 대한 액세스가 발생하지 않습니다.
이 입장은 잘못된 것 같습니다.
테스터는 "모든 이력" 모드에 해당하는 간격을 기억합니다. 사용자 지정 기호 에 기록을 추가하고 터미널을 다시 로드하면 "모든 기록"에 해당하는 간격이 변경되지 않고 그대로 유지됩니다.
또한 전체 기록을 선택하고 전체 기록을 수동으로 설정하면 모든 것이 정상입니다. 수정 해주세요.
표시된 위치에 교차가 충분하지 않습니다. 캐시 항목의 해당 행 삭제.
최적화를 많이 하고 있습니다. 일부는 더 이상 관련이 없습니다. 그리고 이러한 옵션을 제거하는 메커니즘은 없습니다. 때때로 거대한 목록이 빠져서 불필요한 목록 중에서 선택 사항을 찾기 시작합니다.
따라서 그림에 표시된 위치에 십자가에 불필요한 데이터를 삭제하는 것을 고려하십시오.
런타임 에러
결과: 참:거짓:7:4
길이가 다른 이 끈이 갑자기 똑같아진 것 같은가? StringCompare와 비교하는 동안 반대 == 결과를 제공합니다.
메시지를 보내주셔서 감사합니다. 문자별 문자열 비교 동작이 변경되었습니다.
이전 에 문자열이 Z-문자열(널 문자까지)로 비교 되었다면 이제는 PASCAL-문자열로 비교됩니다(길이 고려).
"일반" 문자열(내부에 Z-null 문자 없음)이 있는 기존 코드는 이 변경의 영향을 받지 않습니다.