Vasiliy Sokolov : 추신 특히 MT 개체에 문자열을 저장하는 주제에는 이상한 버그가 하나 있습니다. 데이터 압축을 시작하고 개체 이름에 인쇄할 수 없는 문자를 사용하면 경우에 따라 이 개체에 액세스할 수 없습니다. 글리치는 매우 구체적이고 이에 대해 아는 사람이 거의 없기 때문에 여전히 존재하지만 우연히 발견할 수 있습니다.
이후의 정보 분할 및 추출을 위해 MT 개체의 설명에 문자열을 쓰는 시간과 MT 개체의 설명에서 문자열을 받는 시간을 측정합니다.
결과:
Peter, 당신은 잘못된 것과 잘못된 장소를 테스트하고 있습니다. 테스트하는 것은 문자열 작업의 논리에 따라 거의 동일한 속도를 가져야 합니다.
당신은 내 메시지를 전혀 이해하지 못했습니다.
내 메시지는 문자열을 사용하여 double, long, time, int 등을 전달하는 것을 중단하라는 것이었습니다. 그리고 텍스트를 전송해야 하는 경우 텍스트 문자열을 uchar 배열로 변환합니다. 그리고 결합된 데이터 구조 또는 이러한 구조의 배열을 통해 다양한 유형의 모든 혼합 데이터가 Union을 사용하여 uint 배열로 변환되고 리소스를 통해 전달되고 수신 시 이러한 uint 배열도 Union을 통해 원래 구조로 다시 변환됩니다. 저를 믿으세요. 가죽 끈은 매우 느리기 때문에 가능한 한 항상 끈에서 멀리 떨어져 있어야 합니다. 가죽 끈은 텍스트와 인쇄에만 필요합니다.
그리고 귀하의 예에서 성능 측정의 개념을 완전히 오해했습니다.
또한 OBJPROP_TEXT 속성을 통해 최대 63바이트 크기의 문자열을 전송할 수 있습니다. 그것은 아무것도 아니다.
귀하의 예는 완전히 의미가 없지만 순전히 시연을 위해 더 정확한 것으로 다시 만들었습니다. 이것은 63바이트 크기의 다른 문자열 1000개를 복사할 때 일어난 일입니다.
첨부된 스크립트 코드입니다. MT4와 MT5 모두에서 작동합니다.
MT4:
2018.12 . 1900 : 50 : 14.542 TestStringVsCharArray NZDUSD,Weekly: время через свойство объекта: 2309 правильность копирования - true2018.12 . 1900 : 50 : 14.542 TestStringVsCharArray NZDUSD,Weekly: время через uchar массив: 1882 правильность копирования - true
MT5:
2018.12 . 1900 : 32 : 30.857 TestStringVsCharArray (NZDUSD,M1) время через свойство объекта: 32811 правильность копирования - true2018.12 . 1900 : 33 : 00.678 TestStringVsCharArray (NZDUSD,M1) время через uchar массив: 364 правильность копирования - true
MT5에서 개체 작업은 비동기식이므로 귀하의 방법은 100배 느리고 MT5에는 전혀 적합하지 않습니다. 이제 MT5에 점점 더 많이 베팅해야 합니다.
Aliaksandr Hryshyn : 키릴 문자를 옮기십시오. 그리고 uchar 배열의 문자 코드와 문자열을 비교하면 문자열이 ushort 배열로 나옵니다.
나는 유니코드가 무엇인지 압니다. 그러나 우리의 경우 리소스를 통한 추가 전송을 위해 유니온을 통해 uint 배열을 가져오고 역 문자열 복구 체인을 수신할 때 uchar 배열만 필요합니다. 손실은 없을 것입니다. 그리고 이 작업을 위해 uchar 배열에서 문자를 가져올 필요가 없습니다.
특히 이러한 기능의 마지막 매개변수를 주의 깊게 연구하십시오. 인코딩을 변경할 수 있으며 기본값은 유니코드가 아닙니다.
Peter, 당신은 잘못된 것과 잘못된 장소를 테스트하고 있습니다. 테스트하는 것은 문자열 작업의 논리에 따라 거의 동일한 속도를 가져야 합니다.
Nikolay, 모든 존경심을 가지고 이것은 공허한 단어입니다. 대본을 측정하여 첨부했습니다. "정확하게 접근했다...", "문자열로 작업하는 논리에 따라 거의 같은 속도를 가져야 한다"... 그냥 단어.
니콜라이 셈코 :
...
당신은 내 메시지를 전혀 이해하지 못했습니다.
내 메시지는 문자열을 사용하여 double, long, time, int 등을 전달하는 것을 중단하라는 것이었습니다. 그리고 텍스트를 전송해야 하는 경우 텍스트 문자열을 uchar 배열로 변환합니다. 그리고 결합된 데이터 구조 또는 이러한 구조의 배열을 통해 다양한 유형의 모든 혼합 데이터가 Union을 사용하여 uint 배열로 변환되고 리소스를 통해 전달되고 수신 시 이러한 uint 배열도 Union을 통해 원래 구조로 다시 변환됩니다. 저를 믿으세요. 가죽 끈은 매우 느리기 때문에 가능한 한 항상 끈에서 멀리 떨어져 있어야 합니다. 가죽 끈은 텍스트와 인쇄에만 필요합니다.
내가 완벽하게 이해한 것은 당신의 메시지였습니다. 그리고 그는 틀렸다.
왜요? - 때때로 컨트롤 의 매개변수로 작업하는 시스템을 복잡하게 만들어야 하기 때문입니다 . 매개변수를 저장, 전송 및 관리하기 위한 아키텍처는 훨씬 더 복잡하고 혼란스러워지며 이로 인해 많은 문제가 발생하고 작업이 전반적으로 느려집니다.
내부 아키텍처를 이해하지 못합니다. 프로그램이 어떻게 상호 작용하는지 모르고 유형과 속성에 따라 매개 변수 값을 조작합니다. 당신이 제안하는 것은 모든 것을 훨씬 더 복잡하고 혼란스럽게 만들 것입니다. 그리고 통신 문제를 해결하지 않습니다. 그녀는 여전히 버팀목으로 남을 것입니다.
니콜라이 셈코 :
...
또한 OBJPROP_TEXT 속성을 통해 최대 63바이트 크기의 문자열을 전송할 수 있습니다. 그것은 아무것도 아니다.
귀하의 예는 완전히 의미가 없지만 순전히 시연을 위해 더 정확한 것으로 다시 만들었습니다. 이것은 63바이트 크기의 다른 문자열 1000개를 복사할 때 일어난 일입니다.
...
하나의 MT-object에 대한 설명을 통해 64자의 문자열을 전송할 수 있습니다. 충분 해. 큰 테이블에 데이터를 전달하려면 20-30개의 행이 필요합니다. 큰 테이블이 없으면 최대 2-3개의 행이 필요합니다.
지금은 MT4에 관심이 있습니다.
MT5는 항상 진화하고 있습니다. 개발자는 MT 프로그램의 공유 메모리를 추가하기만 하면 됩니다(리소스를 어지럽힐 필요가 없도록). 그러면 문제가 제거됩니다.
추신 특히 MT 개체에 문자열을 저장하는 주제에는 이상한 버그가 하나 있습니다. 데이터 압축을 시작하고 개체 이름에 인쇄할 수 없는 문자를 사용하면 경우에 따라 이 개체에 액세스할 수 없습니다. 글리치는 매우 구체적이고 이에 대해 아는 사람이 거의 없기 때문에 여전히 존재하지만 우연히 발견할 수 있습니다.
알았습니다. 연습만이 마침내 모든 것을 알아내는 데 도움이 될 것입니다.
친애하는 상대.
다음은 스크립트 코드입니다.
결과:
Peter, 당신은 잘못된 것과 잘못된 장소를 테스트하고 있습니다. 테스트하는 것은 문자열 작업의 논리에 따라 거의 동일한 속도를 가져야 합니다.
당신은 내 메시지를 전혀 이해하지 못했습니다.
내 메시지는 문자열을 사용하여 double, long, time, int 등을 전달하는 것을 중단하라는 것이었습니다. 그리고 텍스트를 전송해야 하는 경우 텍스트 문자열을 uchar 배열로 변환합니다. 그리고 결합된 데이터 구조 또는 이러한 구조의 배열을 통해 다양한 유형의 모든 혼합 데이터가 Union을 사용하여 uint 배열로 변환되고 리소스를 통해 전달되고 수신 시 이러한 uint 배열도 Union을 통해 원래 구조로 다시 변환됩니다. 저를 믿으세요. 가죽 끈은 매우 느리기 때문에 가능한 한 항상 끈에서 멀리 떨어져 있어야 합니다. 가죽 끈은 텍스트와 인쇄에만 필요합니다.
그리고 귀하의 예에서 성능 측정의 개념을 완전히 오해했습니다.
또한 OBJPROP_TEXT 속성을 통해 최대 63바이트 크기의 문자열을 전송할 수 있습니다. 그것은 아무것도 아니다.
귀하의 예는 완전히 의미가 없지만 순전히 시연을 위해 더 정확한 것으로 다시 만들었습니다. 이것은 63바이트 크기의 다른 문자열 1000개를 복사할 때 일어난 일입니다.
첨부된 스크립트 코드입니다. MT4와 MT5 모두에서 작동합니다.
MT4:
MT5:
MT5에서 개체 작업은 비동기식이므로 귀하의 방법은 100배 느리고 MT5에는 전혀 적합하지 않습니다. 이제 MT5에 점점 더 많이 베팅해야 합니다.
그리고 이것은 무엇입니까?:
도움말 읽기
친애하는 상대.
다음은 스크립트 코드입니다.
결과:
우리는 주의 깊게 읽고 결론을 내립니다: https://docs.mql4.com/ru/basis/types/stringconst
동의하지 않는다. 중간 배열로 문자열에 대한 uchar 배열이 필요합니다. 변환은 없지만 간단한 바이트 복사가 있습니다.
동의하지 않는다. 중간 배열로 문자열에 대한 uchar 배열이 필요합니다. 변환은 없지만 간단한 바이트 복사가 있습니다.
키릴 문자를 옮기십시오. 그리고 uchar 배열의 문자 코드와 문자열을 비교하면 문자열이 ushort 배열로 나옵니다.
나는 유니코드가 무엇인지 압니다. 그러나 우리의 경우 리소스를 통한 추가 전송을 위해 유니온을 통해 uint 배열을 가져오고 역 문자열 복구 체인을 수신할 때 uchar 배열만 필요합니다. 손실은 없을 것입니다. 그리고 이 작업을 위해 uchar 배열에서 문자를 가져올 필요가 없습니다.
특히 이러한 기능의 마지막 매개변수를 주의 깊게 연구하십시오. 인코딩을 변경할 수 있으며 기본값은 유니코드가 아닙니다.
Peter, 당신은 잘못된 것과 잘못된 장소를 테스트하고 있습니다. 테스트하는 것은 문자열 작업의 논리에 따라 거의 동일한 속도를 가져야 합니다.
Nikolay, 모든 존경심을 가지고 이것은 공허한 단어입니다. 대본을 측정하여 첨부했습니다. "정확하게 접근했다...", "문자열로 작업하는 논리에 따라 거의 같은 속도를 가져야 한다"... 그냥 단어.
니콜라이 셈코 :
...
당신은 내 메시지를 전혀 이해하지 못했습니다.
내 메시지는 문자열을 사용하여 double, long, time, int 등을 전달하는 것을 중단하라는 것이었습니다. 그리고 텍스트를 전송해야 하는 경우 텍스트 문자열을 uchar 배열로 변환합니다. 그리고 결합된 데이터 구조 또는 이러한 구조의 배열을 통해 다양한 유형의 모든 혼합 데이터가 Union을 사용하여 uint 배열로 변환되고 리소스를 통해 전달되고 수신 시 이러한 uint 배열도 Union을 통해 원래 구조로 다시 변환됩니다. 저를 믿으세요. 가죽 끈은 매우 느리기 때문에 가능한 한 항상 끈에서 멀리 떨어져 있어야 합니다. 가죽 끈은 텍스트와 인쇄에만 필요합니다.
내가 완벽하게 이해한 것은 당신의 메시지였습니다. 그리고 그는 틀렸다.
왜요? - 때때로 컨트롤 의 매개변수로 작업하는 시스템을 복잡하게 만들어야 하기 때문입니다 . 매개변수를 저장, 전송 및 관리하기 위한 아키텍처는 훨씬 더 복잡하고 혼란스러워지며 이로 인해 많은 문제가 발생하고 작업이 전반적으로 느려집니다.
내부 아키텍처를 이해하지 못합니다. 프로그램이 어떻게 상호 작용하는지 모르고 유형과 속성에 따라 매개 변수 값을 조작합니다. 당신이 제안하는 것은 모든 것을 훨씬 더 복잡하고 혼란스럽게 만들 것입니다. 그리고 통신 문제를 해결하지 않습니다. 그녀는 여전히 버팀목으로 남을 것입니다.
...
또한 OBJPROP_TEXT 속성을 통해 최대 63바이트 크기의 문자열을 전송할 수 있습니다. 그것은 아무것도 아니다.
귀하의 예는 완전히 의미가 없지만 순전히 시연을 위해 더 정확한 것으로 다시 만들었습니다. 이것은 63바이트 크기의 다른 문자열 1000개를 복사할 때 일어난 일입니다.
...
하나의 MT-object에 대한 설명을 통해 64자의 문자열을 전송할 수 있습니다. 충분 해. 큰 테이블에 데이터를 전달하려면 20-30개의 행이 필요합니다. 큰 테이블이 없으면 최대 2-3개의 행이 필요합니다.
지금은 MT4에 관심이 있습니다.
MT5는 항상 진화하고 있습니다. 개발자는 MT 프로그램의 공유 메모리를 추가하기만 하면 됩니다(리소스를 어지럽힐 필요가 없도록). 그러면 문제가 제거됩니다.
Nikolai Semko :
...
내 메시지는 문자열을 사용하여 double, long, time, int 등을 전달하는 것을 중단하라는 것이었습니다.
...
그리고 double, long, time, int 등을 보내는 방법. ???
마찬가지로 리소스에 쓰려면 문자열로 변환한 다음 char로 변환해야 합니다.
아니면 lparam,dparam을 통해 제안하고 있습니까?
즉, 이벤트 큐에 과부하가 걸리는 것입니다...
그리고 측정에서 리소스를 저장하고 읽는 데 시간을 추가하는 것을 잊었습니다...
따라서 1000줄을 작성하더라도(리소스를 통해 전송하는 것이 더 좋습니다) 리소스에서 저장하고 검색하는 비용 때문에 속도에서 승리하지 못합니다.