느린 MQL5 컴파일 문제에 대해 다시 언급하고 싶습니다. 약 3개월 전에 나는 이 주제를 제기하려고 했지만 어떤 이유에서인지 이해가 되지 않았고 내 주장이 충분히 설득력이 없었습니다. 따라서 모든 것이 거의 즉시 컴파일되는 이전 빌드(1159)로 롤백했습니다(새 컴파일러에서 내 프로젝트는 20초 만에 컴파일됨).
그리고 일주일 전에 저는 "신의 축복이 그들에게 20초만 주어집니다. 새로운 것을 위해 참을게요."라고 생각하면서 새로운 빌드로 전환하기 위해 새로운 시도를 했습니다. 당연히 새로운 조건에 맞게 코드를 약간 수정해야 했습니다. 그 과정에서 새로운 컴파일러의 몇 가지 버그를 발견했습니다(여기에 대해 썼습니다). 그리고 결과는 무엇입니까? 내 프로젝트가 30초 동안 컴파일되었습니다! 이것이 프로젝트의 복잡성 때문인지 아니면 컴파일러의 다음 "복잡함" 때문인지 모르겠지만 이것은 어떤 프레임워크에도 맞지 않습니다.
이 프로젝트에는 약 700kb의 소스 코드가 있으며 수십 개의 mqh가 포함된 Expert Advisor입니다. 모든 것이 OOP입니다. 이전에 큰 기능이 있기 때문에 속도가 느려질 수 있다고 썼습니다. 나는 이것들 중 몇 가지를 가지고 있었다. 글쎄, 나는 그것들을 작은 부분으로 부수었습니다. 효과는 0입니다.
그리고 가장 놀라운 것은 이 매우 긴 편집에서 의미가 없다는 것입니다. 프로그램의 속도는 이전 컴파일러와 동일하며 특별히 측정되었습니다. "도대체 뭐지?"라는 문구만 나옵니다.
컴파일러에 버그/결함이 있다는 강한 느낌이 듭니다. 그 때문에 처음부터 멍하게 쫓고 있습니다. OnStart() { } 함수만 있는 절대적으로 비어 있는 스크립트가 400ms 이상 컴파일된다는 사실을 다른 방법으로 설명할 수 있습니다! 더미에서 컴파일/최적화하는 데 시간이 너무 오래 걸릴 수 있다는 것은 이해할 수 없습니다. 글쎄, 거기에 작은 함수와 클래스를 추가하면 컴파일 시간이 어떻게 빠르게 증가하는지 관찰할 수 있습니다.
나는 내 하드웨어가 Core i5U와 확실히 거리가 멀다는 것을 즉시 알아차렸습니다. 그러나 이것은 내 프로젝트가 이전 컴파일러에서 1-2초 만에 컴파일되는 것을 방지하지 않습니다. 따라서 거기에 있는 더미는 일반적으로 즉시 컴파일됩니다.
그리고 저도 참고하겠습니다. 컴파일러는 이전에 컴파일된 조각의 캐싱뿐만 아니라 소스 코드의 신원에 대한 진부한 검사조차 완전히 부족합니다. 저것들. 프로젝트를 컴파일한 다음 아무 것도 변경하지 않고 다시 "컴파일" 버튼을 누르고 다시 같은 30초 동안 기다립니다. 글쎄, 어디가 맞는지...
MT 개발자와 대규모 프로젝트를 진행하는 포럼 회원의 의견을 듣고 싶습니다(이 문제에 대해 걱정하는 것은 정말 나뿐입니까?), 누군가 컴파일하는 데 얼마나 걸립니까? 실행 파일 컴파일에 대해 즉시 예약하십시오.
내 프로젝트 에는 당신과 마찬가지로 12개 이상의 소스 파일이 있고 모든 것이 OOP에 있습니다. 반면에 약 20초라고 말하지는 않겠지만 지속적으로 11-14초 이상을 봅니다. 동시에 일종의 캐싱이 발생하기 때문입니다. 아무것도 변경되지 않으면 예측할 수 없는 방향으로 시간이 1-2초씩 변경됩니다. 나는 이전 컴파일러와 새 컴파일러의 프로젝트 어셈블리를 비교하지 않았으며 이전 컴파일러는 모든 것을 몇 배 더 빨리 조립했습니다. 개발자들이 이 순간을 직접 보고 스레드가 모든 것을 수정하는 시점이라고 생각합니다. :) 결국, 한 달에 몇 가지 새로운 베타가 출시되는 것은 헛된 것이 아닙니다. 즉, 무언가를 보고 수정한다는 의미입니다.
동시에 일종의 캐싱이 발생하기 때문입니다. 아무것도 변경되지 않은 경우 시간 은 예측할 수 없는 방향으로 1-2초씩 변경됩니다.
:) 이것은 분명히 오류, 시스템의 다른 프로세스의 영향 및 디스크 캐시입니다. 어쨌든 10-15%는 캐싱이 수행되는 지표가 아닙니다.
나는 이전 컴파일러와 새 컴파일러의 프로젝트 어셈블리를 비교하지 않았으며 이전 컴파일러는 모든 것을 몇 배 더 빨리 조립했습니다. 개발자들이 이 순간을 직접 보고 스레드가 모든 것을 수정하는 시점이라고 생각합니다. :) 결국, 한 달에 몇 가지 새로운 베타가 출시되는 것은 헛된 것이 아닙니다. 즉, 무언가를 보고 수정한다는 의미입니다.
그러나 모두가 침묵한다면 어떻게 그들이 무엇을 볼 수 있겠습니까! 사람들이 다양한 버그에 대해 불평하기 때문에 새로운 베타가 출시됩니다. 그러나 버그가 수정해야 할 중요한 논거라면 다른 모든 것은 ... 오랫동안 설득해야 합니다. 모든 주장을 명확하게 제시하고 그림을 가능한 한 명확하게 설명하는 것처럼 보일지라도 그는 여전히 갈고리 또는 사기꾼으로 반대합니다 :) 그래서 3 개월 전에 저도 그들을 설득하려고했지만 아무도지지하지 않았습니다. 그들을.
결국 MQL에서 대규모 프로젝트 를 수행하는 사람은 거의 없습니다. 그리고 작은 사람들에게는 분명히 몇 초가 추가되기 때문에 증기 목욕을하지 않습니다.
그것이 내가 더 이상 아무것도 증명하려고 하지 않는 이유입니다. 게다가 플러스 프로젝트 는 훨씬 더 오래 빌드되지만 훨씬 더 크지만 실행 파일 또는 라이브러리 파일당, 그리고 프로젝트에 대해 플러스 어셈블리에 몇 분 동안 익숙합니다. 최대 수십 분의 구조 디렉토리가있는 여러 파일의 :) 10-20 초를 기다리는 것은 문제가되지 않습니다 ...
MT4는 888ms를 컴파일합니다.
MT5에서는 동일한 프로젝트가 4103ms에 컴파일됩니다.
저는 MT5에 돈이 없습니다. 저는 센트 계좌를 거래하고 있으며 DC는 5시에 계좌를 여는 데 서두르지 않습니다.
느린 MQL5 컴파일 문제에 대해 다시 언급하고 싶습니다. 약 3개월 전에 나는 이 주제를 제기하려고 했지만 어떤 이유에서인지 이해가 되지 않았고 내 주장이 충분히 설득력이 없었습니다. 따라서 모든 것이 거의 즉시 컴파일되는 이전 빌드(1159)로 롤백했습니다(새 컴파일러에서 내 프로젝트는 20초 만에 컴파일됨).
그리고 일주일 전에 저는 "신의 축복이 그들에게 20초만 주어집니다. 새로운 것을 위해 참을게요."라고 생각하면서 새로운 빌드로 전환하기 위해 새로운 시도를 했습니다. 당연히 새로운 조건에 맞게 코드를 약간 수정해야 했습니다. 그 과정에서 새로운 컴파일러의 몇 가지 버그를 발견했습니다(여기에 대해 썼습니다). 그리고 결과는 무엇입니까? 내 프로젝트가 30초 동안 컴파일되었습니다! 이것이 프로젝트의 복잡성 때문인지 아니면 컴파일러의 다음 "복잡함" 때문인지 모르겠지만 이것은 어떤 프레임워크에도 맞지 않습니다.
이 프로젝트에는 약 700kb의 소스 코드가 있으며 수십 개의 mqh가 포함된 Expert Advisor입니다. 모든 것이 OOP입니다. 이전에 큰 기능이 있기 때문에 속도가 느려질 수 있다고 썼습니다. 나는 이것들 중 몇 가지를 가지고 있었다. 글쎄, 나는 그것들을 작은 부분으로 부수었습니다. 효과는 0입니다.
그리고 가장 놀라운 것은 이 매우 긴 편집에서 의미가 없다는 것입니다. 프로그램의 속도는 이전 컴파일러와 동일하며 특별히 측정되었습니다. "도대체 뭐지?"라는 문구만 나옵니다.
컴파일러에 버그/결함이 있다는 강한 느낌이 듭니다. 그 때문에 처음부터 멍하게 쫓고 있습니다. OnStart() { } 함수만 있는 절대적으로 비어 있는 스크립트가 400ms 이상 컴파일된다는 사실을 다른 방법으로 설명할 수 있습니다! 더미에서 컴파일/최적화하는 데 시간이 너무 오래 걸릴 수 있다는 것은 이해할 수 없습니다. 글쎄, 거기에 작은 함수와 클래스를 추가하면 컴파일 시간이 어떻게 빠르게 증가하는지 관찰할 수 있습니다.
나는 내 하드웨어가 Core i5U와 확실히 거리가 멀다는 것을 즉시 알아차렸습니다. 그러나 이것은 내 프로젝트가 이전 컴파일러에서 1-2초 만에 컴파일되는 것을 방지하지 않습니다. 따라서 거기에 있는 더미는 일반적으로 즉시 컴파일됩니다.
그리고 저도 참고하겠습니다. 컴파일러는 이전에 컴파일된 조각의 캐싱뿐만 아니라 소스 코드의 신원에 대한 진부한 검사조차 완전히 부족합니다. 저것들. 프로젝트를 컴파일한 다음 아무 것도 변경하지 않고 다시 "컴파일" 버튼을 누르고 다시 같은 30초 동안 기다립니다. 글쎄, 어디가 맞는지...
MT 개발자와 대규모 프로젝트를 진행하는 포럼 회원의 의견을 듣고 싶습니다(이 문제에 대해 걱정하는 것은 정말 나뿐입니까?), 누군가 컴파일하는 데 얼마나 걸립니까? 실행 파일 컴파일에 대해 즉시 예약하십시오.
내 프로젝트 에는 당신과 마찬가지로 12개 이상의 소스 파일이 있고 모든 것이 OOP에 있습니다. 반면에 약 20초라고 말하지는 않겠지만 지속적으로 11-14초 이상을 봅니다. 동시에 일종의 캐싱이 발생하기 때문입니다. 아무것도 변경되지 않으면 예측할 수 없는 방향으로 시간이 1-2초씩 변경됩니다. 나는 이전 컴파일러와 새 컴파일러의 프로젝트 어셈블리를 비교하지 않았으며 이전 컴파일러는 모든 것을 몇 배 더 빨리 조립했습니다. 개발자들이 이 순간을 직접 보고 스레드가 모든 것을 수정하는 시점이라고 생각합니다. :) 결국, 한 달에 몇 가지 새로운 베타가 출시되는 것은 헛된 것이 아닙니다. 즉, 무언가를 보고 수정한다는 의미입니다.
터미널의 버전 및 비트 수
v.1375, 64비트
문제에 대한 설명
최신 빌드를 업데이트한 후 에이전트는 최적화 중에 처음 1900-2100이 지난 후 멈춥니다. 업데이트 전에 모든 것이 정상이었고 전문가의 모든 매개 변수와 코드가 동일하게 유지되었습니다.
시퀀싱
최적화가 시작됩니다 . 브로커 발견. 실제 계정. 악기: Si Splice, Vtb Splice, Si 9.16, Vtb 9.16(다른 제품은 시도하지 않음). 간격 월, 분, 15분. 개시 가격 또는 OHLC.
결과
에이전트 - 2000회 통과 후 로컬 및 원격이 실제로 정지되고 백분율이 로드되며 변경 사항은 10분 동안 약 0.01%입니다. 14 에이전트.
예상 결과
이전 빌드에서와 같이 최적화의 통과.
추가 정보
본인 소개: .net 프로그래머, MQL 5, 경험
동시에 일종의 캐싱이 발생하기 때문입니다. 아무것도 변경되지 않은 경우 시간 은 예측할 수 없는 방향으로 1-2초씩 변경됩니다.
:) 이것은 분명히 오류, 시스템의 다른 프로세스의 영향 및 디스크 캐시입니다. 어쨌든 10-15%는 캐싱이 수행되는 지표가 아닙니다.
나는 이전 컴파일러와 새 컴파일러의 프로젝트 어셈블리를 비교하지 않았으며 이전 컴파일러는 모든 것을 몇 배 더 빨리 조립했습니다. 개발자들이 이 순간을 직접 보고 스레드가 모든 것을 수정하는 시점이라고 생각합니다. :) 결국, 한 달에 몇 가지 새로운 베타가 출시되는 것은 헛된 것이 아닙니다. 즉, 무언가를 보고 수정한다는 의미입니다.
그러나 모두가 침묵한다면 어떻게 그들이 무엇을 볼 수 있겠습니까! 사람들이 다양한 버그에 대해 불평하기 때문에 새로운 베타가 출시됩니다. 그러나 버그가 수정해야 할 중요한 논거라면 다른 모든 것은 ... 오랫동안 설득해야 합니다. 모든 주장을 명확하게 제시하고 그림을 가능한 한 명확하게 설명하는 것처럼 보일지라도 그는 여전히 갈고리 또는 사기꾼으로 반대합니다 :) 그래서 3 개월 전에 저도 그들을 설득하려고했지만 아무도지지하지 않았습니다. 그들을.
결국 MQL에서 대규모 프로젝트 를 수행하는 사람은 거의 없습니다. 그리고 작은 사람들에게는 분명히 몇 초가 추가되기 때문에 증기 목욕을하지 않습니다.
그건 그렇고, 당신은 몇 퍼센트를 가지고 있습니까?
... 그들은 여전히 후크 또는 사기꾼에 의해 쉬고 있습니다 :)
열심히 검색했습니다. https://www.mql5.com/ru/forum/88768/page2#comment_2587760
터미널의 버전 및 비트 수
v.1375, 64비트
문제에 대한 설명
최신 빌드를 업데이트한 후 에이전트는 최적화 중에 처음 1900-2100이 지난 후 멈춥니다. 업데이트 전에 모든 것이 정상이었고 전문가의 모든 매개 변수와 코드가 동일하게 유지되었습니다.
시퀀싱
최적화가 시작됩니다 . 브로커 발견. 실제 계정. 악기: Si Splice, Vtb Splice, Si 9.16, Vtb 9.16(다른 제품은 시도하지 않음). 간격 월, 분, 15분. 개시 가격 또는 OHLC.
결과
에이전트 - 2000회 통과 후 로컬 및 원격이 실제로 정지되고 백분율이 로드되며 변경 사항은 10분 동안 약 0.01%입니다. 14 에이전트.
예상 결과
이전 빌드에서와 같이 최적화의 통과.
추가 정보
본인 소개: .net 프로그래머, MQL 5, 경험
모든 Expert Advisor에서 이 동작이 관찰됩니까?
그래도 로그는 아프지 않습니다. 서비스 데스크에 티켓을 제출하십시오.
터미널 로그 - 좋습니다. 전략 테스터 및 테스트 에이전트의 로그가 더 흥미 롭습니다.
+ 티켓에 Expert Advisor의 EX5 이상을 포함합니다(조사 후 제거합니다) + 최적화에 사용된 매개변수에 대한 설명.