그리고 당신은 Windows 메시지에 대해 ... 그래서 무엇을? 자체 작성 dll이 없는 Windows의 다른 프로그램 간의 데이터 교환을 위한 더 빠른 대안이 있습니까?
내 말에 상처받은 거 이해해, 내 버전은 똑똑해. 음, 첫째, 나는 이것을 주장하지 않고 단지 가정했습니다. 그리고 두 번째로 메모리 매핑 과 비교할 때 테스트 코드 로 내 가정을 지원했습니다. 그리고 당신은 가정조차 논박하려는 경우 선언적 진술에만 논박하지 마십시오. 저를 설득하고 자체 작성 dll 없이 터미널 간 데이터 교환의 더 빠른 구현을 지적해 주시면 대단히 감사하겠습니다.
RAM 디스크를 통한 옵션이 훨씬 빠를 것이라는 점을 배제하지 않습니다. 그러나 이것은 이 RAM 디스크의 설치와 구성이 필요하기 때문에 약간 다른 주제입니다.
알렉세이 나보이코프 :
물론이죠. 탬버린으로 어떤 춤을 추나요?
for ( int i= 0 ; i< 56 ; i++) if (U.a[i]== 0 ) m[ 2 *i+ 1 ]= 2 ; else m[ 2 *i]=U.a[i];
그들은 또한 나를 위해 탬버린을 발견했습니다. 이것은 평범함입니다. 그런데 이 사소함은 틱 구조를 얻기 위한 전체 블록이 90μs(90,000ns)에 완료될 때 50-60ns에 완료됩니다. 수신됩니다. 게다가 기억력이 두 배로 늘어난 지금 이 순간이 혼란스러울 뿐이라고 썼다 .
그래서 내 버전은 작은 데이터 구조를 교환하는 데 매우 편리하고 간단하며 똑똑한 것 같습니다.
소스에는 문자열로/에서 모든 데이터를 입력/검색할 수 있는 크로스 플랫폼 기능(파일 Data_String.mqh )이 포함되어 있습니다. 예를 들어 사용자 이벤트 의 문자열 매개변수(sparam)를 사용하여 MQL 프로그램 간에 임의의 데이터를 편리하게 교환할 수 있습니다.
우와! CryptEncode 및 CryptDecode 같은 기능에 대해서도 몰랐습니다. 고맙습니다! 나는 공부할 것이다. 추신 하지만 지금까지 언뜻보기에 이것은 모두 첨단 기술이지만 CryptEncode 함수가 여기에서 탬버린이라고 하는 것보다 2배 느리게(마이크로초 대 수십 나노초) 실행되기 때문에 미친 듯이 느립니다.
for ( int i= 0 ; i< 56 ; i++) if (U.a[i]== 0 ) m[ 2 *i+ 1 ]= 2 ; else m[ 2 *i]=U.a[i];
내 말에 상처받은 거 이해해, 내 버전은 똑똑해. 음, 첫째, 나는 이것을 주장하지 않고 단지 가정했습니다. 그리고 두 번째로, 나는 메모리 매핑 과 비교할 때 테스트 코드 로 내 가정을 지지했습니다.
네, 저는 "기민"하지는 않지만 " 기존의 모든 솔루션보다 빠를 가능성이 있습니다 ." 그래서 습격 없이 몇 마디만 했습니다. 그리고 이 말은 상당히 정당했습니다. 어떤 이유에서인지 처음에는 완고하게 거부하고("아마 다른 코드 를 보았을 것입니다.") , 나중에는 "그래서 어쩌죠!"라는 입장이 됩니다. 그래서 여전히 파리를 커틀릿에서 분리합시다.
먼저, 내 게시물은 테스트 코드를 게시하기 전에 작성되었습니다. 둘째, MemoryMapping(또는 언급된 MQL 래퍼)과 관련하여 나는 어디에서나 그것이 빠르게 작동한다고 주장한 적이 없습니다. 또한 여기 이 프로젝트의 토론 스레드에서 브레이크를 만드는 작성자의 실수와 해결 방법을 지적했습니다. 따라서 이미 테스트를 시작했다면 다른 사람의 잘못된 결정이 아닌 기본 형식 으로 테스트하십시오.
네, 저는 "기민"하지는 않지만 " 기존의 모든 솔루션보다 빠를 가능성이 있습니다 ." 그래서 습격 없이 몇 마디만 했습니다. 그리고 이 말은 상당히 정당했습니다. 어떤 이유에서인지 처음에는 완고하게 거부하고("아마 다른 코드 를 보았을 것입니다.") , 나중에는 "그래서 어쩌죠!"라는 입장이 됩니다. 그래서 여전히 파리를 커틀릿에서 분리합시다.
첫째, 내 게시물은 테스트 코드를 게시하기 전에 작성되었습니다. 둘째, MemoryMapping(또는 언급된 MQL 래퍼)과 관련하여 나는 어디에서나 그것이 빠르게 작동한다고 주장한 적이 없습니다. 또한 여기 이 프로젝트의 토론 스레드에서 브레이크를 만드는 작성자의 실수와 해결 방법을 지적했습니다. 따라서 이미 테스트를 시작했다면 다른 사람의 잘못된 결정이 아닌 기본 형식 으로 테스트하십시오.
확인. 동의. 너무 큰 소리로 말했다.
WinAPI를 사용하여 두 터미널을 연결할 때 kernel32.dll 대신 user32.dll을 사용하는 것이 더 빠를 수 있다고 말하고 싶었습니다. 내가 만난 모든 구현은 kernel32.dll을 사용했습니다.
글쎄, 당신은 이미 너무 멀리 갔다) 먼저 메시지 대기열을 통과합니다. 둘째, 몇 가지 추가 변환(앞뒤)을 수행해야 합니다. 또한 일종의 검증이 진행 중입니다.
그런데 구조체의 크기를 명시적으로 지정해서는 안 됩니다. 이것이 바로 sizeof의 용도입니다.
아마도 당신은 다른 코드를 보았을 것입니다.
위협은 내 버전에서 내가 좋아하지 않는 유일한 것입니다. 0은 문자열의 끝으로 간주됩니다. 나는 더 쉬운 해결책이 있다는 것을 척수로 느끼고 있지만 그것을 찾지 못했습니다. 그러나 여전히 더 빠르게 작동합니다.
SetWindowText/GetWindowText 가 메시지를 통해 전송되지 않습니까?
왕복 전환이 없습니다.
물론이죠. 그리고 탬버린으로 어떤 종류의 춤을 추나요?
SetWindowText/GetWindowText 가 메시지를 통해 전송되지 않습니까?
그리고 당신은 Windows 메시지에 대해 ... 그래서 무엇을? 자체 작성 dll이 없는 Windows의 다른 프로그램 간의 데이터 교환을 위한 더 빠른 대안이 있습니까?
내 말에 상처받은 거 이해해, 내 버전은 똑똑해. 음, 첫째, 나는 이것을 주장하지 않고 단지 가정했습니다. 그리고 두 번째로 메모리 매핑 과 비교할 때 테스트 코드 로 내 가정을 지원했습니다.
그리고 당신은 가정조차 논박하려는 경우 선언적 진술에만 논박하지 마십시오. 저를 설득하고 자체 작성 dll 없이 터미널 간 데이터 교환의 더 빠른 구현을 지적해 주시면 대단히 감사하겠습니다.
RAM 디스크를 통한 옵션이 훨씬 빠를 것이라는 점을 배제하지 않습니다. 그러나 이것은 이 RAM 디스크의 설치와 구성이 필요하기 때문에 약간 다른 주제입니다.
물론이죠. 탬버린으로 어떤 춤을 추나요?
그들은 또한 나를 위해 탬버린을 발견했습니다. 이것은 평범함입니다. 그런데 이 사소함은 틱 구조를 얻기 위한 전체 블록이 90μs(90,000ns)에 완료될 때 50-60ns에 완료됩니다. 수신됩니다. 게다가 기억력이 두 배로 늘어난 지금 이 순간이 혼란스러울 뿐이라고 썼다 .
그래서 내 버전은 작은 데이터 구조를 교환하는 데 매우 편리하고 간단하며 똑똑한 것 같습니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
라이브러리: HistoryTicks
자동 거래 , 2018.03.29 11:09
우와!
CryptEncode 및 CryptDecode 같은 기능에 대해서도 몰랐습니다. 고맙습니다!
나는 공부할 것이다.
추신 하지만 지금까지 언뜻보기에 이것은 모두 첨단 기술이지만 CryptEncode 함수가 여기에서 탬버린이라고 하는 것보다 2배 느리게(마이크로초 대 수십 나노초) 실행되기 때문에 미친 듯이 느립니다.
내 말에 상처받은 거 이해해, 내 버전은 똑똑해. 음, 첫째, 나는 이것을 주장하지 않고 단지 가정했습니다. 그리고 두 번째로, 나는 메모리 매핑 과 비교할 때 테스트 코드 로 내 가정을 지지했습니다.
네, 저는 "기민"하지는 않지만 " 기존의 모든 솔루션보다 빠를 가능성이 있습니다 ." 그래서 습격 없이 몇 마디만 했습니다. 그리고 이 말은 상당히 정당했습니다. 어떤 이유에서인지 처음에는 완고하게 거부하고("아마 다른 코드 를 보았을 것입니다." ) , 나중에는 "그래서 어쩌죠!"라는 입장이 됩니다. 그래서 여전히 파리를 커틀릿에서 분리합시다.
먼저, 내 게시물은 테스트 코드를 게시하기 전에 작성되었습니다. 둘째, MemoryMapping(또는 언급된 MQL 래퍼)과 관련하여 나는 어디에서나 그것이 빠르게 작동한다고 주장한 적이 없습니다. 또한 여기 이 프로젝트의 토론 스레드에서 브레이크를 만드는 작성자의 실수와 해결 방법을 지적했습니다. 따라서 이미 테스트를 시작했다면 다른 사람의 잘못된 결정이 아닌 기본 형식 으로 테스트하십시오.
추신 하지만 지금까지는 언뜻 보기에 이것은 모두 첨단 기술이지만 CryptEncode 함수가 여기에서 탬버린이라고 하는 것보다 2배 느리게(마이크로초 대 수십 나노초) 실행되기 때문에 미친 듯이 느립니다.
무엇을 위한 속도인가?
네, 저는 "기민"하지는 않지만 " 기존의 모든 솔루션보다 빠를 가능성이 있습니다 ." 그래서 습격 없이 몇 마디만 했습니다. 그리고 이 말은 상당히 정당했습니다. 어떤 이유에서인지 처음에는 완고하게 거부하고("아마 다른 코드 를 보았을 것입니다." ) , 나중에는 "그래서 어쩌죠!"라는 입장이 됩니다. 그래서 여전히 파리를 커틀릿에서 분리합시다.
첫째, 내 게시물은 테스트 코드를 게시하기 전에 작성되었습니다. 둘째, MemoryMapping(또는 언급된 MQL 래퍼)과 관련하여 나는 어디에서나 그것이 빠르게 작동한다고 주장한 적이 없습니다. 또한 여기 이 프로젝트의 토론 스레드에서 브레이크를 만드는 작성자의 실수와 해결 방법을 지적했습니다. 따라서 이미 테스트를 시작했다면 다른 사람의 잘못된 결정이 아닌 기본 형식 으로 테스트하십시오.
확인. 동의. 너무 큰 소리로 말했다.
WinAPI를 사용하여 두 터미널을 연결할 때 kernel32.dll 대신 user32.dll을 사용하는 것이 더 빠를 수 있다고 말하고 싶었습니다. 내가 만난 모든 구현은 kernel32.dll을 사용했습니다.
무엇을 위한 속도인가?
죄송합니다. 질문을 이해하지 못했습니다.
당신은 묻습니다 - 터미널 간 브리지의 데이터 교환 속도가 필요합니까?
죄송합니다. 질문을 이해하지 못했습니다.
당신은 묻습니다 - 우리는 터미널 사이의 다리의 데이터 교환 속도가 필요한 이유는 무엇입니까?
네.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
mql5 언어의 특징, 미묘함 및 작업 방법
니콜라이 셈코 , 2018.09.21 13:20
추신: 하지만 지금까지 언뜻 보기에 이것은 모두 첨단 기술이지만 CryptEncode 함수가 여기에서 탬버린이라고 하는 것보다 2배 더 느리게( 마이크로초 대 수십 나노초 ) 실행되기 때문에 미친 듯이 느립니다.