따라서 원본에는 SubWindow_out이 있는 ChartID_in도 있습니다. 완전한 아날로그를 만드십시오.
ChartID_in 과 SubWindow_out을 추가하는 것은 전혀 어렵지 않습니다. 그러나 나는 완전한 아날로그를 만드는 것을 목표로 하는 것이 아니라 ChartXYToTimePrice()의 느림을 보여주기 위해 이 함수를 만들었을 뿐입니다.
void XYToTimePrice( long chart_id, int x, int y, int & sub_window, datetime &time, double &price, int id)
{
staticint left_bar; // номер самого левого бара на экранеstaticint WidBar;
staticint Wid;
staticint Hei;
staticdouble y_min;
staticdouble y_max;
staticint PerSec= PeriodSeconds ();
staticbool ChartChange= true ;
if (id== CHARTEVENT_CHART_CHANGE ) { ChartChange= true ; return ; }
if (ChartChange) // если было изменение чатра после последнего вычисления
{
left_bar=( int ) ChartGetInteger (chart_id, CHART_FIRST_VISIBLE_BAR , sub_window); // номер самого левого бара на экране
Wid=( int ) ChartGetInteger (chart_id, CHART_WIDTH_IN_PIXELS , sub_window); // ширина экрана в пикселях
WidBar=( int ) ChartGetInteger (chart_id, CHART_WIDTH_IN_BARS , sub_window); // ширина экрана в барах
Hei=( int ) ChartGetInteger (chart_id, CHART_HEIGHT_IN_PIXELS , sub_window); // высота экрана в пикселях
y_min= ChartGetDouble (chart_id, CHART_PRICE_MIN , sub_window); // макс. цена на экране
y_max= ChartGetDouble (chart_id, CHART_PRICE_MAX , sub_window); // мин. цена на экране
}
if (x>Wid || x< 0 || y< 0 || y>Hei) return ; // выходим если точка (x,y) за пределами экрана
price=y_min+(Hei-y)*(y_max-y_min)/Hei;
int NrBar=left_bar-( int )(( double )x/(( double )Wid/( double )WidBar));
datetime T[ 1 ];
if (NrBar>= 0 ) CopyTime ( NULL , 0 ,NrBar, 1 ,T);
else { CopyTime ( NULL , 0 , 0 , 1 ,T); T[ 0 ]+= fabs (NrBar)*PerSec;}
ChartChange= false ;
time=T[ 0 ];
}
그러나 진실은 내 기능에 여전히 이벤트의 추가 매개변수 ID가 필요하다는 것입니다. 그리고 이 기능은 1픽셀의 양초 두께로 원본과 거의 동일하게 작동하지만 필요한 경우 수정할 수 있습니다.
ChartID_in과 SubWindow_out을 추가하는 것은 전혀 어렵지 않습니다. 그러나 나는 완전한 아날로그를 만드는 것을 목표로 하는 것이 아니라 ChartXYToTimePrice()의 느림을 보여주기 위해 이 함수를 만들었을 뿐입니다.
그러나 진실은 내 기능에 여전히 이벤트의 추가 매개변수 ID가 필요하다는 것입니다. 그리고 이 기능은 1픽셀의 양초 두께로 원본과 거의 동일하게 작동하지만 필요한 경우 수정할 수 있습니다.
ChartXYToTimePrice의 이상한 기능도 발견했습니다. 실행 시간은 차트의 막대 수에 정비례합니다.
이것은 그것을 계산하는 알고리즘의 "이상함"을 나타냅니다. 즉, 순환 합산에 관해서는 그러한 문제의 최적 솔루션에 대해 매우 이상합니다.
XYToTimePrice 함수의 속도는 막대 수에 관계없이 동일합니다.
그리고 사실을 말하자면 ChartGetInteger 및 ChartGetDouble 함수의 실행 속도 역시 엄청나게 비싸고 매우 이상한 기능을 가지고 있습니다. 예를 들어 기능
ChartGetDouble ( 0 , CHART_PRICE_MAX );
함수보다 20-100배 빠르게 실행:
ChartGetDouble ( 0 , CHART_PRICE_MIN );
MAX가 MIN 뒤에 오는 경우:
그러나 교환하면 상황이 반전됩니다.
저것들. 논리적으로 보입니다. 다시 계산되는 동일한 함수는 이전 함수 호출에서 이미 계산되고 저장된 데이터를 사용합니다. 그러나 그것은 단지 일부 미친 계산이 진행 중이고 많은 중간 데이터를 생성하고 차트의 최대(또는 최소) 가격의 단순한 이중 값을 계산하기 위한 배열을 생성한다는 것을 의미합니다. 이 값은 이미 일부 변수에 있으며 귀하는 그냥 가져 가야합니다.
이 효과가 일종의 프로파일링 기능으로 인한 것이며 가짜라는 것을 배제하지는 않습니다. 그러나 이러한 기능의 느림은 거짓이 아닙니다.
ChartXYToTimePrice의 이상한 기능도 발견했습니다. 실행 시간은 차트의 막대 수에 정비례합니다.
이것은 그것을 계산하는 알고리즘의 "이상함"을 나타냅니다. 즉, 순환 합산에 관해서는 그러한 문제의 최적 솔루션에 대해 매우 이상합니다.
XYToTimePrice 함수의 속도는 막대 수에 관계없이 동일합니다.
그리고 사실을 말하자면 ChartGetInteger 및 ChartGetDouble 함수의 실행 속도 역시 엄청나게 비싸고 매우 이상한 기능을 가지고 있습니다. 예를 들어 기능
함수보다 20-100배 빠르게 실행:
MAX가 MIN 뒤에 오는 경우:
그러나 교환하면 상황이 반전됩니다.
저것들. 논리적으로 보입니다. 다시 계산되는 동일한 함수는 이전 함수 호출에서 이미 계산되고 저장된 데이터를 사용합니다. 그러나 그것은 단지 일부 미친 계산이 진행 중이고 많은 중간 데이터를 생성하고 차트의 최대(또는 최소) 가격의 단순한 이중 값을 계산하기 위한 배열을 생성한다는 것을 의미합니다. 이 값은 이미 일부 변수에 있으며 귀하는 그냥 가져 가야합니다.
이 효과가 일종의 프로파일링 기능으로 인한 것이며 가짜라는 것을 배제하지는 않습니다. 그러나 이러한 기능의 느림은 거짓이 아닙니다.
차트에 대한 데이터를 요청하는 기능이 느려지는 것은 구현 자체가 아니라 정보를 보내고 받는 방식에 있습니다. 이러한 기능의 구현 자체는 원시적이며 차트의 막대 수에 의존하지 않습니다.
그러나 그래프는 많은 소스에 정보가 분산되는 개체이기 때문에 모든 제어는 메시지 대기열을 기반으로 합니다. 이전 요청이 처리되지 않은 동안 다음 요청이 기다리고 있습니다.
그러나 동일한 일정에 대한 여러 요청이 연속적으로 있는 경우 이러한 후속 요청은 매우 빠르게 실행됩니다. 아무도 그들과 첫 번째 요청 사이에 끼어들 수 없었기 때문입니다.
차트에 대한 데이터를 요청하는 기능이 느려지는 것은 구현 자체가 아니라 정보를 보내고 받는 방식에 있습니다. 이러한 기능의 구현 자체는 원시적이며 차트의 막대 수에 의존하지 않습니다.
그러나 그래프는 많은 소스에 정보가 분산되는 개체이기 때문에 모든 제어는 메시지 대기열을 기반으로 합니다. 이전 요청이 처리되지 않은 동안 다음 요청이 기다리고 있습니다.
그러나 동일한 일정에 대한 여러 요청이 연속적으로 있는 경우 이러한 후속 요청은 매우 빠르게 실행됩니다. 아무도 그들과 첫 번째 요청 사이에 끼어들 수 없었기 때문입니다.
순리에 맡기다. 그러나 이것을 안다고 해서 더 쉬워지지는 않습니다. Slava는 간단한 프로그래머를 올바르게 이해합니다. 이전 게시물의 테스트 표시기 예제는 ChartXYToTimePrice() 요청의 평균 실행 시간이 5000 - 10000마이크로초임을 분명히 보여줍니다(FullHD 화면에서 1픽셀의 양초 두께와 MT의 표준 창 포함). 이 시간 동안 무엇을 할 수 있습니까?
예를 들어 이 시간 동안 500개의 채워진 원으로 동일한 화면에 이미지를 만들고 화면에 표시할 수 있습니다.
대기열이 있는데도 대기열에 시간이 오래 걸리는 이유는 무엇입니까? 척도의 한쪽에는 화면에 표시되는 500개의 원을 픽셀 단위로 형성하고 다른 쪽에는 두 자리 숫자에 대한 간단한 요청이 있습니다. 그리고 무게도 똑같습니다. 여기 순무를 긁고 퍼즐을 맞추지 못하는 단순한 프로그래머가 앉아 있습니다.
순리에 맡기다. 그러나 이것을 안다고 해서 더 쉬워지지는 않습니다. Slava는 간단한 프로그래머를 올바르게 이해합니다. 이전 게시물의 테스트 표시기 예제는 ChartXYToTimePrice() 요청의 평균 실행 시간이 5000 - 10000마이크로초임을 분명히 보여줍니다(FullHD 화면에서 1픽셀의 양초 두께와 MT의 표준 창 포함). 이 시간 동안 무엇을 할 수 있습니까?
예를 들어 이 시간 동안 500개의 채워진 원으로 동일한 화면에 이미지를 만들고 화면에 표시할 수 있습니다.
대기열이 있는데도 대기열에 시간이 오래 걸리는 이유는 무엇입니까? 척도의 한쪽에는 화면에 표시되는 500개의 원을 픽셀 단위로 형성하고 다른 쪽에는 두 자리 숫자에 대한 간단한 요청이 있습니다. 그리고 무게도 똑같습니다. 여기 순무를 긁고 퍼즐을 맞추지 못하는 단순한 프로그래머가 앉아 있습니다.
얘들 아, 나는 MT5의 안드로이드에서 www.mql5.com의 로그인과 비밀번호를 끊임없이 입력하는 것에 지쳤습니다.
왜 계속 떨어지는거죠???
저에게도 주기적으로 물어보는데 로그인/비밀번호를 입력하지 않고 뒤로가기 버튼만 누르면 로그인이 되어있습니다.
ChartXYToTimePrice()와 같은 매우 유용한 함수가 실행 시간 측면에서 왜 그렇게 비싼가요?
XYToTimePrice()와 유사한 기능을 작성했으며 훨씬 빠르게 작동합니다. 최대 수백 배 더 빠릅니다.
따라서 원본에는 SubWindow_out 이 있는 ChartID_in도 있습니다. 완전한 아날로그를 만드십시오.
따라서 원본에는 SubWindow_out이 있는 ChartID_in도 있습니다. 완전한 아날로그를 만드십시오.
ChartID_in 과 SubWindow_out을 추가하는 것은 전혀 어렵지 않습니다. 그러나 나는 완전한 아날로그를 만드는 것을 목표로 하는 것이 아니라 ChartXYToTimePrice()의 느림을 보여주기 위해 이 함수를 만들었을 뿐입니다.
그러나 진실은 내 기능에 여전히 이벤트의 추가 매개변수 ID가 필요하다는 것입니다. 그리고 이 기능은 1픽셀의 양초 두께로 원본과 거의 동일하게 작동하지만 필요한 경우 수정할 수 있습니다.
ChartID_in과 SubWindow_out을 추가하는 것은 전혀 어렵지 않습니다. 그러나 나는 완전한 아날로그를 만드는 것을 목표로 하는 것이 아니라 ChartXYToTimePrice()의 느림을 보여주기 위해 이 함수를 만들었을 뿐입니다.
그러나 진실은 내 기능에 여전히 이벤트의 추가 매개변수 ID가 필요하다는 것입니다. 그리고 이 기능은 1픽셀의 양초 두께로 원본과 거의 동일하게 작동하지만 필요한 경우 수정할 수 있습니다.
ChartXYToTimePrice의 이상한 기능도 발견했습니다. 실행 시간은 차트의 막대 수에 정비례합니다.
이것은 그것을 계산하는 알고리즘의 "이상함"을 나타냅니다. 즉, 순환 합산에 관해서는 그러한 문제의 최적 솔루션에 대해 매우 이상합니다.
XYToTimePrice 함수의 속도는 막대 수에 관계없이 동일합니다.
그리고 사실을 말하자면 ChartGetInteger 및 ChartGetDouble 함수의 실행 속도 역시 엄청나게 비싸고 매우 이상한 기능을 가지고 있습니다. 예를 들어 기능
함수보다 20-100배 빠르게 실행:
MAX가 MIN 뒤에 오는 경우:
그러나 교환하면 상황이 반전됩니다.
저것들. 논리적으로 보입니다. 다시 계산되는 동일한 함수는 이전 함수 호출에서 이미 계산되고 저장된 데이터를 사용합니다. 그러나 그것은 단지 일부 미친 계산이 진행 중이고 많은 중간 데이터를 생성하고 차트의 최대(또는 최소) 가격의 단순한 이중 값을 계산하기 위한 배열을 생성한다는 것을 의미합니다. 이 값은 이미 일부 변수에 있으며 귀하는 그냥 가져 가야합니다.
이 효과가 일종의 프로파일링 기능으로 인한 것이며 가짜라는 것을 배제하지는 않습니다. 그러나 이러한 기능의 느림은 거짓이 아닙니다.
필요한 경우 수정할 수 있습니다.
결과가 일치할 때 두 함수의 속도 특성을 비교하는 정확성에 대해 이야기하는 것은 아마도 여전히 타당할 것입니다. 마셔 주세요.
얘들 아, 나는 MT5의 안드로이드에서 www.mql5.com의 로그인과 비밀번호를 끊임없이 입력하는 것에 지쳤습니다.
왜 계속 떨어지는거죠???
서비스 데스크에 씁니다 . 로그를 첨부합니다. 고맙습니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
오류, 버그, 질문
fxsaber , 2017.10.04 09:13
이것은 여러 번 작성되었습니다. 어떤 이유로 작동하지 않습니다.
ChartXYToTimePrice의 이상한 기능도 발견했습니다. 실행 시간은 차트의 막대 수에 정비례합니다.
이것은 그것을 계산하는 알고리즘의 "이상함"을 나타냅니다. 즉, 순환 합산에 관해서는 그러한 문제의 최적 솔루션에 대해 매우 이상합니다.
XYToTimePrice 함수의 속도는 막대 수에 관계없이 동일합니다.
그리고 사실을 말하자면 ChartGetInteger 및 ChartGetDouble 함수의 실행 속도 역시 엄청나게 비싸고 매우 이상한 기능을 가지고 있습니다. 예를 들어 기능
함수보다 20-100배 빠르게 실행:
MAX가 MIN 뒤에 오는 경우:
그러나 교환하면 상황이 반전됩니다.
저것들. 논리적으로 보입니다. 다시 계산되는 동일한 함수는 이전 함수 호출에서 이미 계산되고 저장된 데이터를 사용합니다. 그러나 그것은 단지 일부 미친 계산이 진행 중이고 많은 중간 데이터를 생성하고 차트의 최대(또는 최소) 가격의 단순한 이중 값을 계산하기 위한 배열을 생성한다는 것을 의미합니다. 이 값은 이미 일부 변수에 있으며 귀하는 그냥 가져 가야합니다.
이 효과가 일종의 프로파일링 기능으로 인한 것이며 가짜라는 것을 배제하지는 않습니다. 그러나 이러한 기능의 느림은 거짓이 아닙니다.
차트에 대한 데이터를 요청하는 기능이 느려지는 것은 구현 자체가 아니라 정보를 보내고 받는 방식에 있습니다. 이러한 기능의 구현 자체는 원시적이며 차트의 막대 수에 의존하지 않습니다.
그러나 그래프는 많은 소스에 정보가 분산되는 개체이기 때문에 모든 제어는 메시지 대기열을 기반으로 합니다. 이전 요청이 처리되지 않은 동안 다음 요청이 기다리고 있습니다.
그러나 동일한 일정에 대한 여러 요청이 연속적으로 있는 경우 이러한 후속 요청은 매우 빠르게 실행됩니다. 아무도 그들과 첫 번째 요청 사이에 끼어들 수 없었기 때문입니다.
차트에 대한 데이터를 요청하는 기능이 느려지는 것은 구현 자체가 아니라 정보를 보내고 받는 방식에 있습니다. 이러한 기능의 구현 자체는 원시적이며 차트의 막대 수에 의존하지 않습니다.
그러나 그래프는 많은 소스에 정보가 분산되는 개체이기 때문에 모든 제어는 메시지 대기열을 기반으로 합니다. 이전 요청이 처리되지 않은 동안 다음 요청이 기다리고 있습니다.
그러나 동일한 일정에 대한 여러 요청이 연속적으로 있는 경우 이러한 후속 요청은 매우 빠르게 실행됩니다. 아무도 그들과 첫 번째 요청 사이에 끼어들 수 없었기 때문입니다.
순리에 맡기다. 그러나 이것을 안다고 해서 더 쉬워지지는 않습니다. Slava는 간단한 프로그래머를 올바르게 이해합니다. 이전 게시물의 테스트 표시기 예제는 ChartXYToTimePrice() 요청의 평균 실행 시간이 5000 - 10000마이크로초임을 분명히 보여줍니다(FullHD 화면에서 1픽셀의 양초 두께와 MT의 표준 창 포함). 이 시간 동안 무엇을 할 수 있습니까?
예를 들어 이 시간 동안 500개의 채워진 원으로 동일한 화면에 이미지를 만들고 화면에 표시할 수 있습니다.
대기열이 있는데도 대기열에 시간이 오래 걸리는 이유는 무엇입니까?
척도의 한쪽에는 화면에 표시되는 500개의 원을 픽셀 단위로 형성하고 다른 쪽에는 두 자리 숫자에 대한 간단한 요청이 있습니다. 그리고 무게도 똑같습니다.
여기 순무를 긁고 퍼즐을 맞추지 못하는 단순한 프로그래머가 앉아 있습니다.
순리에 맡기다. 그러나 이것을 안다고 해서 더 쉬워지지는 않습니다. Slava는 간단한 프로그래머를 올바르게 이해합니다. 이전 게시물의 테스트 표시기 예제는 ChartXYToTimePrice() 요청의 평균 실행 시간이 5000 - 10000마이크로초임을 분명히 보여줍니다(FullHD 화면에서 1픽셀의 양초 두께와 MT의 표준 창 포함). 이 시간 동안 무엇을 할 수 있습니까?
예를 들어 이 시간 동안 500개의 채워진 원으로 동일한 화면에 이미지를 만들고 화면에 표시할 수 있습니다.
대기열이 있는데도 대기열에 시간이 오래 걸리는 이유는 무엇입니까?
척도의 한쪽에는 화면에 표시되는 500개의 원을 픽셀 단위로 형성하고 다른 쪽에는 두 자리 숫자에 대한 간단한 요청이 있습니다. 그리고 무게도 똑같습니다.
여기 순무를 긁고 퍼즐을 맞추지 못하는 단순한 프로그래머가 앉아 있습니다.
동기 명령과 비동기 명령의 차이를 느꼈습니다.