함수 실행의 마이크로초에 대해 걱정하는 것은 최적화 모드에서만 합리적입니다. 실시간으로는 상관없습니다. 그리고 Comment는 10배 느리더라도 실시간으로 Expert Advisor의 성능에 어떤 역할도 하지 않습니다.
그러나 테스터에서 최대한 빨리 실행되도록 Expert Advisors를 작성하는 사람이 거의 없다는 사실은 사실입니다.
이를 달성하는 방법에 대한 FAQ를 작성하십시오. 모든 생각을 한 곳에 모으십시오. 블로그에 올려드리고, 다른 곳에서는 유튜브에 영상을 만들어 MQ채널에 올리도록 하겠습니다. 당신은 의심할 여지 없이 그러한 체계적인 것들에 대한 방대한 경험을 가지고 있습니다. 공동선을 위해 그것을 공유합시다!
Alexey Volchanskiy : 이를 달성하는 방법에 대한 FAQ를 작성하십시오. 모든 생각을 한 곳에 모으십시오.
이에 대한 훌륭한 스레드가 있습니다. 아마도 누군가는 이 스레드의 많은 게시물을 기반으로 섹션에서 FAQ를 컴파일하는 데 엄청난 노력과 시간을 할애할 것입니다.
그리고 속도를 위해 항상 동일한 레시피인 TesterBenchmark + profiler 를 사용합니다. 그리고 물론 테스터의 기능과 실제 사이의 합리적인 중간을 찾기 위해. MT4Orders는 그렇게 작성되었습니다. 그곳에서 테스터에서의 빠른 작업과 현실에서의 이상적인 작업에 대한 내기가 이루어졌습니다. 이렇게 하려면 실제 생활에서 필요한 동일한 테스터의 일부(때로는 비용이 많이 드는) 검사를 수행할 필요가 없다는 것을 이해해야 합니다. 그 결과 상당한 비용이 절감됩니다. 글쎄, 같은 기록의 캐싱 등. 저것들. 때때로 테스터와 현실 세계에 대해 서로 다른 논리를 갖는 내장형 라이브러리를 작성해야 합니다. Trade.mqh는 불행히도 그런 라이브러리가 아닙니다.
이를 위한 훌륭한 스레드가 있습니다. 아마도 누군가는 이 스레드의 많은 게시물을 기반으로 섹션에서 FAQ를 컴파일하는 데 엄청난 노력과 시간을 할애할 것입니다.
그리고 속도를 위해 항상 동일한 레시피인 TesterBenchmark + profiler 를 사용합니다. 그리고 물론 테스터의 기능과 실제 사이의 합리적인 중간을 찾기 위해. MT4Orders는 그렇게 작성되었습니다. 그곳에서 테스터에서의 빠른 작업과 현실에서의 이상적인 작업에 대한 내기가 이루어졌습니다. 이렇게 하려면 실제 생활에서 필요한 동일한 테스터의 일부(때로는 비용이 많이 드는) 검사를 수행할 필요가 없다는 것을 이해해야 합니다. 그 결과 상당한 비용이 절감됩니다. 글쎄, 같은 기록의 캐싱 등. 저것들. 내장 에 테스터와 실제 논리가 다른 경우가 있는 라이브러리를 작성해야 합니다. Trade.mqh는 불행히도 그런 라이브러리가 아닙니다.
이전 포스트에서 이야기한 내용입니다. 지정된 브랜치에 대해 FAQ를 작성하는 것이 최대 작업입니다. 최적화 속도 향상에 대한 FAQ를 작성하는 간단한 작업을 수행해 보겠습니다. 코드가 있으면 생각을 작성하면 됩니다. 코드를 추가하세요. 나는 그것을 요약하고 빗질하려고 노력할 것이고, 우리는 동의하고 그것을 게시 할 것입니다. 나는 비디오, 좋은 경험, 문제를 만들 것입니다.
그리고 그는 그것을 올바르게 합니다. 이것은 개체의 속성을 변경한 후 ChartRedraw를 수행하지 않는 것만큼 논리적입니다. 용어 사용
ChartRedraw는 각각의 쓰기가 아니라 대량 쓰기 후에 호출되어야 합니다.
예, 하지만 전체 창의 1% 미만인 130x80 픽셀과 같은 작은 캔버스가 있는 경우 현재 정보를 표시해야 합니다. MT4에서는 Update(false)를 사용하여 전체 화면을 다시 그리지 않고 이 작업을 수행할 수 있지만 MT5에서는 매번 전체 화면을 다시 그려야 합니다. 그리고 이것은 이미 몇 자릿수보다 리소스 집약적입니다. 그리고 이것은 테스트가 아니라 작업 주제입니다.
Nikolai Semko : 예, 하지만 전체 창의 1% 미만인 130x80 픽셀과 같은 작은 캔버스가 있는 경우 현재 정보를 표시해야 합니다. MT4에서는 Update(false)를 사용하여 전체 화면을 다시 그리지 않고 이 작업을 수행할 수 있지만 MT5에서는 매번 전체 화면을 다시 그려야 합니다. 그리고 이것은 이미 몇 자릿수보다 리소스 집약적입니다. 그리고 이것은 테스트가 아니라 작업 주제입니다.
그리고 모든 것을 생각하고 근본적으로 개선하는 문제는 무엇입니까?
"작동하고 훌륭함" 모드에는 이미 MQL4-MQL5 라이브러리 유형이 있으므로 머리카락을 뜯어내야 합니다. 모든 진지한 사람들은 그것을 사용하여 두 플랫폼의 속도를 비교합니다.
이제 당신은 생각하지 않고 "MT5에서는 더 느립니다"라고 말하면서 서두를 다른 공예품을 만들 것을 제안합니다.
아무것도 이해하지 못했습니다. fxsaber에 시간과 열망이 있다면 다시 한 번 제안합니다.
1. 테스터/옵티마이저 모드에서 불필요한 기능(현재는 그래픽)을 비활성화하는 MT5용 라이브러리(MT4의 경우 옵션)를 만듭니다.
2. 이렇게 하려면 이러한 값비싼 함수를 정의로 래핑하고 작동 모드에 따라 활성화하거나 비활성화합니다.
너무 감정적으로 문제에 접근할 필요가 없습니다. 아무도 MT5를 만나지 않습니다.
테스터의 코드 성능을 한 줄로 측정할 수 있는 범용 도구가 있습니다. 볼 것이 많았습니다. 특히 단일 실행은 최적화 실행보다 느립니다.
댓글 주제에 개발자 들이 답을 주었습니다 . 그 동안 나 자신 도 한 줄로 최적화 속도를 1.5~2배 높였습니다.
그리고 SD에서 그들은 성능에 중요한 뉘앙스 에 대해 이야기했습니다.
함수 실행의 마이크로초에 대해 걱정하는 것은 최적화 모드에서만 합리적입니다. 실시간으로는 상관없습니다. 그리고 Comment는 10배 느리더라도 실시간으로 Expert Advisor의 성능에 어떤 역할도 하지 않습니다.
그러나 테스터에서 최대한 빨리 실행되도록 Expert Advisors를 작성하는 사람이 거의 없다는 사실은 사실입니다.
이를 달성하는 방법에 대한 FAQ를 작성하십시오. 모든 생각을 한 곳에 모으십시오.
이에 대한 훌륭한 스레드가 있습니다. 아마도 누군가는 이 스레드의 많은 게시물을 기반으로 섹션에서 FAQ를 컴파일하는 데 엄청난 노력과 시간을 할애할 것입니다.
그리고 속도를 위해 항상 동일한 레시피인 TesterBenchmark + profiler 를 사용합니다. 그리고 물론 테스터의 기능과 실제 사이의 합리적인 중간을 찾기 위해. MT4Orders는 그렇게 작성되었습니다. 그곳에서 테스터에서의 빠른 작업과 현실에서의 이상적인 작업에 대한 내기가 이루어졌습니다. 이렇게 하려면 실제 생활에서 필요한 동일한 테스터의 일부(때로는 비용이 많이 드는) 검사를 수행할 필요가 없다는 것을 이해해야 합니다. 그 결과 상당한 비용이 절감됩니다. 글쎄, 같은 기록의 캐싱 등. 저것들. 때때로 테스터와 현실 세계에 대해 서로 다른 논리를 갖는 내장형 라이브러리를 작성해야 합니다. Trade.mqh는 불행히도 그런 라이브러리가 아닙니다.
이를 위한 훌륭한 스레드가 있습니다. 아마도 누군가는 이 스레드의 많은 게시물을 기반으로 섹션에서 FAQ를 컴파일하는 데 엄청난 노력과 시간을 할애할 것입니다.
그리고 속도를 위해 항상 동일한 레시피인 TesterBenchmark + profiler 를 사용합니다. 그리고 물론 테스터의 기능과 실제 사이의 합리적인 중간을 찾기 위해. MT4Orders는 그렇게 작성되었습니다. 그곳에서 테스터에서의 빠른 작업과 현실에서의 이상적인 작업에 대한 내기가 이루어졌습니다. 이렇게 하려면 실제 생활에서 필요한 동일한 테스터의 일부(때로는 비용이 많이 드는) 검사를 수행할 필요가 없다는 것을 이해해야 합니다. 그 결과 상당한 비용이 절감됩니다. 글쎄, 같은 기록의 캐싱 등. 저것들. 내장 에 테스터와 실제 논리가 다른 경우가 있는 라이브러리를 작성해야 합니다. Trade.mqh는 불행히도 그런 라이브러리가 아닙니다.
최적화 속도 향상에 대한 FAQ를 작성하는 간단한 작업을 수행해 보겠습니다.
이타주의는 때때로 좋습니다. 그러나 시간은 내가 아니라 가족의 것입니다.
겸손한 코드와 레시피를 공유합니다. 이 정도면 충분할 것 같습니다.
나는 비밀이 없습니다.
그리고 그는 그것을 올바르게 합니다. 이것은 개체의 속성을 변경한 후 ChartRedraw를 수행하지 않는 것만큼 논리적입니다. 용어 사용
ChartRedraw는 각각의 쓰기가 아니라 대량 쓰기 후에 호출되어야 합니다.
예, 하지만 전체 창의 1% 미만인 130x80 픽셀과 같은 작은 캔버스가 있는 경우 현재 정보를 표시해야 합니다. MT4에서는 Update(false)를 사용하여 전체 화면을 다시 그리지 않고 이 작업을 수행할 수 있지만 MT5에서는 매번 전체 화면을 다시 그려야 합니다. 그리고 이것은 이미 몇 자릿수보다 리소스 집약적입니다. 그리고 이것은 테스트가 아니라 작업 주제입니다.
캔버스 및 기타 작업 중에 화면이 부분적으로 다시 그려지지 않을 것이라고 확신합니다.
이타주의는 때때로 좋습니다. 그러나 시간은 내가 아니라 가족의 것입니다.
겸손한 코드와 레시피를 공유합니다. 이 정도면 충분할 것 같습니다.
나는 비밀이 없습니다.
겸손은 위대하다! 저도 겸손한 사람입니다. 이타주의는 대부분의 경우 죽은 테레사 수녀를 향한 것입니다. 때로는이 나쁜 질병의 뿌리 - 이타주의 - 내 안에 싹이 트지만)))
캔버스 및 기타 작업 중에 화면이 부분적으로 다시 그려지지 않을 것이라고 확신합니다.
예, 그는 틀렸습니다. MT4에서 ChartRedraw가 없는 ResourceCreate 는 매번 캔버스를 다시 그립니다. 가끔 이 작업을 수행하지만 MT5는 전혀 수행하지 않습니다.
예, 물론, 나는 바보입니다. 결국 하드웨어 수준에서 화면 컨텍스트는 화면의 일부만 변경할 수 없고 전체만 변경할 수 있습니다.
나는 작은 지연 Sleep(10)을 도입했을 때 이것을 깨달았습니다.