그는 실제 프로젝트에서 직접 호출이나 가상 호출이 영향을 미치지 않는다는 것을 보여주었습니다.
대부분의 비용은 MQL 프로그램의 거의 모든 시간을 소비하는 시스템 기능 호출에 소비됩니다. 호출 설정 비용은 페이로드에 비해 무시할 수 있습니다.
+100 네, 맞습니다!
또한, 지나치게 자란 클래스를 일부 기능이 다른 클래스(포함/분해)에서 수행되는 방식으로 다시 작성해야 할 때 전체 성능이 향상되고 코드에 대한 제어가 증가한다는 사실을 알게 되었습니다. 저것들. 실제로 Integer 및 구식 C 애호가가 우리에게 증명하려고 시도하는 것과 반대의 상황이 관찰됩니다. 클래스 수는 증가하고 메소드 수는 증가하며 반대로 성능은 증가합니다.
그는 그것을 어디에서 보여 주었습니까? 일부 기능 이름과 측정값이 있는 테이블 - 이것이 인수입니까? 우리는 텔레파시가 아닙니다. 기능 코드를 보고 나서도 여전히 무언가에 대해 이야기할 수 있어야 합니다.
나는 누군가에게 무엇이든 증명하고 누군가를 설득하는 데 관심이 없습니다. 믿거 나 말거나. 그러나 소스 코드의 존재는 당신에게 아무 것도 주지 않을 것이라는 점에 주목합니다. 전반적인 복잡성은 동일하지 않습니다. 소스 코드를 분석한 후에도 "글쎄, 뭔가가 거기에서 호출되고, 무언가가 고려되고, 어딘가에서 무언가가 취해지지만 정확히 무엇인지 명확하지 않으므로 아무 것도 다시 증명되지 않았습니다."라고 말할 것입니다.
또한, 지나치게 자란 클래스를 일부 기능이 다른 클래스(포함/분해)에서 수행되는 방식으로 다시 작성해야 할 때 전체 성능이 향상되고 코드에 대한 제어가 증가한다는 사실을 알게 되었습니다. 저것들. 실제로 Integer 및 구식 C 애호가가 우리에게 증명하려고 시도하는 것과 반대의 상황이 관찰됩니다. 클래스 수는 증가하고 메소드 수는 증가하며 반대로 성능은 증가합니다.
C-4 : 그러나 소스 코드의 존재는 당신에게 아무 것도 주지 않을 것이라는 점에 주목합니다. 전반적인 복잡성은 동일하지 않습니다. 소스 코드를 분석한 후에도 "글쎄, 뭔가가 거기에서 호출되고, 무언가가 고려되고, 어딘가에서 무언가가 취해지지만 정확히 무엇인지 명확하지 않으므로 아무 것도 다시 증명되지 않았습니다."라고 말할 것입니다.
일반적으로 아마도 그렇습니다. 개별 기능은 거의 아무 것도 말하지 않을 것입니다. 당신의 프로그램에 대한 대화를 시작하는 것이 요점은 무엇이었습니까? 다른 모든 사람들에게 그것이 찔린 돼지라면 말입니다.
사실, 우리가 관심을 갖는 가장 중요한 것은 가상 메소드 전환의 총 수와 이에 소요된 총 시간입니다. 여기 테이블에 5백만 번 실행되는 음영 처리된 함수가 있습니다. 뭔지는 모르겠지만 가장 간단한 동작을 가진 가상 메서드가 있을 수 있습니다. 하지만 500만원은 작은 금액이다. 나는 당신이 프로그램에서 무거운 계산을하지 않았으므로 논의 할 것이 없다고 생각합니다. 이제 선형 방정식 시스템 30000x30000이 계산되고 행렬 요소에 대한 액세스가 가상 방법을 통해 수행되었다고 가정해 보겠습니다. 그러면 이미 이야기할 내용이 있습니다.
그는 실제 프로젝트에서 직접 호출이나 가상 호출이 영향을 미치지 않는다는 것을 보여주었습니다.
대부분의 비용은 MQL 프로그램의 거의 모든 시간을 소비하는 시스템 기능 호출에 소비됩니다. 호출 설정 비용은 페이로드에 비해 무시할 수 있습니다.
그는 그것을 어디에서 보여 주었습니까? 일부 기능 이름과 측정값이 있는 테이블 - 이것이 인수입니까? 우리는 텔레파시가 아닙니다. 기능 코드를 보고 나서도 여전히 무언가에 대해 이야기할 수 있어야 합니다.
그는 그것을 어디에서 보여 주었습니까? 일부 기능 이름과 측정값이 있는 테이블 - 이것이 인수입니까? 우리는 전혀 텔레파시가 아닙니다. 기능 코드를 보고 나서도 여전히 무언가에 대해 이야기할 수 있어야 합니다.
그는 실제 프로젝트에서 직접 호출이나 가상 호출이 영향을 미치지 않는다는 것을 보여주었습니다.
대부분의 비용은 MQL 프로그램의 거의 모든 시간을 소비하는 시스템 기능 호출에 소비됩니다. 호출 설정 비용은 페이로드에 비해 무시할 수 있습니다.
+100 네, 맞습니다!
또한, 지나치게 자란 클래스를 일부 기능이 다른 클래스(포함/분해)에서 수행되는 방식으로 다시 작성해야 할 때 전체 성능이 향상되고 코드에 대한 제어가 증가한다는 사실을 알게 되었습니다. 저것들. 실제로 Integer 및 구식 C 애호가가 우리에게 증명하려고 시도하는 것과 반대의 상황이 관찰됩니다. 클래스 수는 증가하고 메소드 수는 증가하며 반대로 성능은 증가합니다.
그는 그것을 어디에서 보여 주었습니까? 일부 기능 이름과 측정값이 있는 테이블 - 이것이 인수입니까? 우리는 텔레파시가 아닙니다. 기능 코드를 보고 나서도 여전히 무언가에 대해 이야기할 수 있어야 합니다.
+100 네, 맞습니다!
또한, 지나치게 자란 클래스를 일부 기능이 다른 클래스(포함/분해)에서 수행되는 방식으로 다시 작성해야 할 때 전체 성능이 향상되고 코드에 대한 제어가 증가한다는 사실을 알게 되었습니다. 저것들. 실제로 Integer 및 구식 C 애호가가 우리에게 증명하려고 시도하는 것과 반대의 상황이 관찰됩니다. 클래스 수는 증가하고 메소드 수는 증가하며 반대로 성능은 증가합니다.
자기 최면의 새로운 방법? 하자, 하자.
Vasily, 당신은 여전히 여기에서 내가 증명하려고 했던 것을 읽을 것입니다.
그러나 소스 코드의 존재는 당신에게 아무 것도 주지 않을 것이라는 점에 주목합니다. 전반적인 복잡성은 동일하지 않습니다. 소스 코드를 분석한 후에도 "글쎄, 뭔가가 거기에서 호출되고, 무언가가 고려되고, 어딘가에서 무언가가 취해지지만 정확히 무엇인지 명확하지 않으므로 아무 것도 다시 증명되지 않았습니다."라고 말할 것입니다.
일반적으로 아마도 그렇습니다. 개별 기능은 거의 아무 것도 말하지 않을 것입니다. 당신의 프로그램에 대한 대화를 시작하는 것이 요점은 무엇이었습니까? 다른 모든 사람들에게 그것이 찔린 돼지라면 말입니다.
사실, 우리가 관심을 갖는 가장 중요한 것은 가상 메소드 전환의 총 수와 이에 소요된 총 시간입니다. 여기 테이블에 5백만 번 실행되는 음영 처리된 함수가 있습니다. 뭔지는 모르겠지만 가장 간단한 동작을 가진 가상 메서드가 있을 수 있습니다. 하지만 500만원은 작은 금액이다. 나는 당신이 프로그램에서 무거운 계산을하지 않았으므로 논의 할 것이 없다고 생각합니다. 이제 선형 방정식 시스템 30000x30000이 계산되고 행렬 요소에 대한 액세스가 가상 방법을 통해 수행되었다고 가정해 보겠습니다. 그러면 이미 이야기할 내용이 있습니다.
자기 최면의 새로운 방법? 하자, 하자.
Vasily, 당신은 여전히 여기에서 내가 증명하려고 했던 것을 읽을 것입니다.
드미트리, 나는 당신을 찬성하지도 반대하지도 않습니다. 이해하려면 컴파일러의 인라인 처리에 대해 알아야 하지만 MQ에 대해 이 정보를 여는 것은 디컴파일러를 작성하는 데 도움이 되는 것과 같습니다.
여기에서는 Renat만이 그러한 정보를 가지고 있으므로(토론하는 사람들로부터), 우리는 말에 의존해야 할 것입니다. 다른 방법이 보이지 않습니다.
그가 당신이 시험을 잘못 치르고 있다고 말한다면 분명히 그렇습니다.
질문은 다릅니다. 이 경우 MQ만 올바르게 테스트할 수 있으며 이것이 달성되어야 합니다.
그들이 시험을 위해 시험하라, 내 말은 너희를 거스른다. 그리고 당신은 증명할 수 없는 것을 증명하려고 합니다. 비교할 대상 없이 당신의 진술을 증명하거나 반증하는 것은 불가능합니다.
디컴파일러는 여기서 중요하지 않습니다.
잔인하게 최적화되고 선형 코드로 퇴화되는 단순화된 퇴화 사례를 테스트하지 않도록 컴파일러 최적화 기술을 이해하고 알아야 합니다. 헛되이 chtoli는 4세대 컴파일러를 출시했습니다.
바로 그 내용입니다.
이제 선형 방정식 시스템 30000x30000이 계산되고 행렬 요소에 대한 액세스가 가상 방법을 통해 수행되었다고 가정해 보겠습니다. 그러면 이미 이야기할 내용이 있습니다.
이러한 경우 첫 번째 리팩토링은 속도를 100배 증가시킵니다. 또한 가상 통화는 비용 측면에서 10위를 차지할 것입니다.
즉, 예시가 비현실적입니다.
그럼 모두 어셈블러로 작성해 봅시다. 어느 쪽이든 더 빠를 것입니다.
나는 문제의 본질을 이해하지 못한다. 1MB의 코드가 포함된 Expert Advisor나 지표를 본 적이 없습니다.
어떤 함수를 호출하는 것에도 시간이 걸립니다. 기능을 없애자!
OOP를 사용하면 대규모 프로젝트를 훨씬 더 편리하게 제어할 수 있습니다.
또한 코드 실행 속도는 브로커에 대한 핑 시간 과 주문에 대한 브로커의 응답만큼 중요하지 않은 경우가 많습니다.
HFT 알고리즘을 살펴보십시오. 최대 성능이 필요하지만 복잡한 계산을 찾을 수 없습니다.
추신. A 지점에서 B 지점으로 이동하려면 원칙적으로 슈퍼카나 경력 BELAZ가 필요하지 않습니다. 오토바이로 충분합니다!