이것은 사소한 문제입니다. 예, 컴파일러 최적화 프로그램은 아직 이러한 문자열 순간을 최적화할 수 없습니다. 그러나 속도 저하 문제는 정확히 문자열 할당에 있습니다.
그리고 그것이 가장 중요하다고 생각합니다. 할당을 가속화하거나 코드에서 제거하는 것 중 어떤 효과가 더 있습니까? 예, 물론 이 할당이 그 자체로 필요한 상황이 있지만 얼마나 자주 발생합니까? 대부분의 경우 임시 변수만 처리합니다.
또한 이러한 문자열 작업의 속도를 얼마나 높일 수 있는지도 문제입니다. 당신은 시간이 단축될 수 있는 것처럼 주장합니다. 나는 의심한다. 이미 반복적으로 모든 것이 최적화되고 다시 최적화되었습니다. 글쎄, 다른 20-30 %를 짜낼 수있게하십시오. 이것은 날씨를 만들지 않습니다.
예를 들어, FIBO에서 매월 실제 틱으로 실행하면 약 100만 틱이 됩니다. 매 틱마다 PositionGetString 값을 가져와서 무언가와 비교하면 성능은 허용되지만 비교하기 전에 먼저 함수의 결과를 문자열 변수에 할당한 다음 비교하면 실행 시간이 1초 정도 증가합니다.
이것이 사소한 것 같으면 이것은 잘못된 비전입니다. 이러한 어드바이저가 수천 패스에 대해 최적화 모드에서 시작되면 이것이 추가됩니다. 두 번째 결과는 추가입니다. 대기 시간. 저것들. 무해한 문자열 할당은 추가를 유발할 수 있습니다. 최적화하는 동안 몇 시간을 기다려야 합니다. 조심하고 이 뉘앙스를 고려하십시오.
이 접근 방식은 매우 비효율적이라는 점을 이해하시기 바랍니다. 매 틱마다 PositionGetString을 얻는 이유는 무엇입니까? 그곳에서 무엇을 바꿀 수 있습니까? 특히 자신이이 직책을 열었음을 고려하면. 모든 것은 이미 미리 알려져 있습니다.
일반적으로 성능 최적화에 대해 이야기하는 경우 우선 프로그램 자체의 논리를 최적화해야 합니다.
또한 이러한 문자열 작업의 속도를 얼마나 높일 수 있는지도 문제입니다. 당신은 시간이 단축될 수 있는 것처럼 주장합니다. 나는 의심한다. 이미 반복적으로 모든 것이 최적화되고 다시 최적화되었습니다. 글쎄, 다른 20-30 %를 짜낼 수있게하십시오. 이것은 날씨를 만들지 않습니다.
MQL에 다중 상속이 없다는 것은 물론 우울합니다. 그러나 즉석에서 나갈 수 있습니다: 템플릿과 매크로 - 그것들이 없는 곳)
여기에 옵션이 쌓여 있습니다. 모든 소스 클래스는 상위 클래스를 정의하는 템플릿으로 선언되어야 합니다.
class CBase { }; // базовый класс// Макросы, задающие список наследования:#define INHERIT1(T) T<CBase>
#define INHERIT2(T1, T2) T2<INHERIT1(T1)>
#define INHERIT3(T1, T2, T3) T3<INHERIT2(T1,T2)>
#define INHERIT4(T1, T2, T3, T4) T4<INHERIT3(T1,T2,T3)>
// Различные пользовательские классы:template < typename TParent>
class A : public TParent { public : void a() { Print ( "A" ); } };
template < typename TParent>
class B : public TParent { public : void b() { Print ( "B" ); } };
template < typename TParent>
class C : public TParent { public : void c() { Print ( "C" ); } };
class X : public INHERIT3(A, B, C) { }; // Объявляем класс, наследуемый от A, B, Ctemplate < typename T>
void SomeFunc(B<T>& obj) { obj.b(); } // Проверочная функция, принимающая класс BvoidOnInit ()
{
X x;
x.a();
x.b();
x.c();
SomeFunc(x);
}
물론 여기에는 클래스가 병렬로 상속되지 않고(실제 다중 상속에서와 같이) 순차적으로(우리가 설정한 순서대로) 상속된다는 사실 때문에 뉘앙스가 있습니다. 특히 과부하가 발생하면 우선 순위가 다릅니다. 또한 동일한 템플릿 클래스가 상속 체인에 여러 번 참여하면 서로 관련이 없는 완전히 다른 클래스가 됩니다. 그래서 여기서 조심해야 합니다. 그러나 인터페이스에는 문제가 없으며 제한 없이 상속할 수 있습니다.
MQL에 다중 상속이 없다는 것은 물론 우울합니다. 그러나 즉석에서 나갈 수 있습니다: 템플릿과 매크로 - 그것들이 없는 곳)
여기에 옵션이 쌓여 있습니다. 모든 소스 클래스는 상위 클래스를 정의하는 템플릿으로 선언되어야 합니다.
물론 여기에는 클래스가 병렬로 상속되지 않고(실제 다중 상속에서와 같이) 순차적으로(우리가 설정한 순서대로) 상속된다는 사실 때문에 뉘앙스가 있습니다. 특히 과부하가 발생하면 우선 순위가 다릅니다. 또한 동일한 템플릿 클래스가 상속 체인에 여러 번 참여하면 서로 관련이 없는 완전히 다른 클래스가 됩니다. 그래서 여기서 조심해야 합니다. 그러나 인터페이스에는 문제가 없으며 제한 없이 상속할 수 있습니다.
이것은 사소한 문제입니다. 예, 컴파일러 최적화 프로그램은 아직 이러한 문자열 순간을 최적화할 수 없습니다. 그러나 속도 저하 문제는 정확히 문자열 할당에 있습니다.
그리고 그것이 가장 중요하다고 생각합니다. 할당을 가속화하거나 코드에서 제거하는 것 중 어떤 효과가 더 있습니까? 예, 물론 이 할당이 그 자체로 필요한 상황이 있지만 얼마나 자주 발생합니까? 대부분의 경우 임시 변수만 처리합니다.
또한 이러한 문자열 작업의 속도를 얼마나 높일 수 있는지도 문제입니다. 당신은 시간이 단축될 수 있는 것처럼 주장합니다. 나는 의심한다. 이미 반복적으로 모든 것이 최적화되고 다시 최적화되었습니다. 글쎄, 다른 20-30 %를 짜낼 수있게하십시오. 이것은 날씨를 만들지 않습니다.
그런데 문자열 변수를 상수로 선언해 보셨나요?
그래서 이런 글을 쓴다면
일반 조건의 끝에서 OrderSymbol-조건을 푸시하는 것이 항상 더 좋습니다.
글쎄, 그것은 말할 필요도 없다. 그리고 OrderSymbol은 MQL과 마찬가지로 아무 관련이 없습니다. 문자열 연산은 그 자체로 비용이 많이 들기 때문에 헛되이 사용해서는 안 됩니다.
글쎄, 그 사이에
fxsaber :
예를 들어, FIBO에서 매월 실제 틱으로 실행하면 약 100만 틱이 됩니다. 매 틱마다 PositionGetString 값을 가져와서 무언가와 비교하면 성능은 허용되지만 비교하기 전에 먼저 함수의 결과를 문자열 변수에 할당한 다음 비교하면 실행 시간이 1초 정도 증가합니다.
이것이 사소한 것 같으면 이것은 잘못된 비전입니다. 이러한 어드바이저가 수천 패스에 대해 최적화 모드에서 시작되면 이것이 추가됩니다. 두 번째 결과는 추가입니다. 대기 시간. 저것들. 무해한 문자열 할당은 추가를 유발할 수 있습니다. 최적화하는 동안 몇 시간을 기다려야 합니다. 조심하고 이 뉘앙스를 고려하십시오.
이 접근 방식은 매우 비효율적이라는 점을 이해하시기 바랍니다. 매 틱마다 PositionGetString을 얻는 이유는 무엇입니까? 그곳에서 무엇을 바꿀 수 있습니까? 특히 자신이이 직책을 열었음을 고려하면. 모든 것은 이미 미리 알려져 있습니다.
일반적으로 성능 최적화에 대해 이야기하는 경우 우선 프로그램 자체의 논리를 최적화해야 합니다.
또한 이러한 문자열 작업의 속도를 얼마나 높일 수 있는지도 문제입니다. 당신은 시간이 단축될 수 있는 것처럼 주장합니다. 나는 의심한다. 이미 반복적으로 모든 것이 최적화되고 다시 최적화되었습니다. 글쎄, 다른 20-30 %를 짜낼 수있게하십시오. 이것은 날씨를 만들지 않습니다.
의 요인.
그런데 문자열 변수를 상수로 선언해 보셨나요?
매 틱마다 PositionGetString을 얻는 이유는 무엇입니까? 그곳에서 무엇을 바꿀 수 있습니까? 특히 자신이이 직책을 열었음을 고려하면. 모든 것은 이미 미리 알려져 있습니다.
일반적으로 성능 최적화에 대해 이야기하는 경우 우선 프로그램 자체의 논리를 최적화해야 합니다.
그러한 논리를 가진 전투 로봇 - 그런 시간 간격에 EURUSD에 열린 포지션이 없어야 합니다. 있으면 닫습니다.
GBPUSD 포지션이 열려 있습니다. 매 틱마다 OrderSymbol을 확인하지 않고 위의 조건을 충족하는 방법은 무엇입니까?
또는 당신은 특별 작성을 제안합니다. 테스터를 위한 어드바이저 버전? 여기 전투 로봇을 사서 테스트하고 있는 남자가 있습니다. 모든 것이 테스터의 속도를 위해 특별히 최적화되어 있다고 마켓에 작성하시겠습니까?
그러한 논리를 가진 전투 로봇 - 그런 시간 간격에 EURUSD에 열린 포지션이 없어야 합니다. 있으면 닫습니다.
GBPUSD 포지션이 열려 있습니다. 매 틱마다 OrderSymbol을 확인하지 않고 위의 조건을 충족하는 방법은 무엇입니까?
또는 당신은 특별 작성을 제안합니다. 테스터를 위한 어드바이저 버전? 여기 전투 로봇을 사서 테스트하고 있는 남자가 있습니다. 모든 것이 테스터의 속도를 위해 특별히 최적화되어 있다고 마켓에 작성하시겠습니까?
글쎄요, 현재 열려 있는 위치 의 티켓만 확인하는 것으로 충분합니다(따라서 배열을 유지). 새 티켓이 나타나면 다른 모든 검사를 수행하십시오. 같은 것을 백만 번 확인하는 이유는 무엇입니까?
그런데 MQL5에는 거래 이벤트가 있습니다. 따라서 모든 눈금을 확인할 필요가 없습니다.
글쎄요, 현재 열려 있는 위치 의 티켓만 확인하는 것으로 충분합니다(따라서 배열을 유지).
훨씬 저렴하지 않을 것입니다.
그런데 MQL5에는 거래 이벤트가 있습니다. 따라서 각 눈금을 확인할 필요가 전혀 없습니다.
때때로 그들은 크로스 플랫폼 솔루션을 작성합니다. 또한 모든 거래 이벤트를 수신한다는 보장은 없으며 수신할 수도 없습니다.
훨씬 저렴하지 않을 것입니다.
정수 연산의 차이가 문자열 연산보다 훨씬 저렴하지 않습니까? 글쎄, 당신이 원하는대로.
정수 연산의 차이가 문자열 연산보다 약간 더 저렴합니까? 글쎄, 당신이 원하는대로.
이게 왜 필요한지 이해가 안 가는데 저를 먹으셨군요. 그리고 일련의 티켓이 있는 옵션이 더 생산적이라는 데 동의해야 합니다.
사실, 일부 논리의 관점에서이 옵션은 매우 인공적으로 보이며 이미 프로그램의 논리적 구성이 아니라 기술적 인 뉘앙스에 설정되어 있습니다.
그러나 어쨌든 나는 그것을 취할 것입니다. 물론 코드 기반에서 이러한 접근 방식을 본 적이 없습니다.
MQL에 다중 상속이 없다는 것은 물론 우울합니다. 그러나 즉석에서 나갈 수 있습니다: 템플릿과 매크로 - 그것들이 없는 곳)
여기에 옵션이 쌓여 있습니다. 모든 소스 클래스는 상위 클래스를 정의하는 템플릿으로 선언되어야 합니다.
물론 여기에는 클래스가 병렬로 상속되지 않고(실제 다중 상속에서와 같이) 순차적으로(우리가 설정한 순서대로) 상속된다는 사실 때문에 뉘앙스가 있습니다. 특히 과부하가 발생하면 우선 순위가 다릅니다. 또한 동일한 템플릿 클래스가 상속 체인에 여러 번 참여하면 서로 관련이 없는 완전히 다른 클래스가 됩니다. 그래서 여기서 조심해야 합니다. 그러나 인터페이스에는 문제가 없으며 제한 없이 상속할 수 있습니다.
MQL에 다중 상속이 없다는 것은 물론 우울합니다. 그러나 즉석에서 나갈 수 있습니다: 템플릿과 매크로 - 그것들이 없는 곳)
여기에 옵션이 쌓여 있습니다. 모든 소스 클래스는 상위 클래스를 정의하는 템플릿으로 선언되어야 합니다.
물론 여기에는 클래스가 병렬로 상속되지 않고(실제 다중 상속에서와 같이) 순차적으로(우리가 설정한 순서대로) 상속된다는 사실 때문에 뉘앙스가 있습니다. 특히 과부하가 발생하면 우선 순위가 다릅니다. 또한 동일한 템플릿 클래스가 상속 체인에 여러 번 참여하면 서로 관련이 없는 완전히 다른 클래스가 됩니다. 그래서 여기서 조심해야 합니다. 그러나 인터페이스에는 문제가 없으며 제한 없이 상속할 수 있습니다.
반갑습니다. 비결은 템플릿을 TParent에 적용하는 것 입니다. 전에 이런 것을 본 적이 없습니다.