내 접근 방식. 코어 - 엔진. - 페이지 83

 
Реter Konow :
엔진과 어드바이저는 커뮤니케이션의 흐름에서 작동합니다. 각 테이블 셀은 몇 글자입니다. 이 외에도 - 많은 다른 요소가 값, 상태 등을 전송합니다. 신속하게 문자열을 교환하고 OnChartEvent() 이벤트 대기열을 로드하지 않아야 합니다.

SQL을 사용하고 머리에 땀을 흘리지 마십시오 :-)

 
Nikolai Semko :
자원과 노조의 도움으로 어떻게 할 생각조차 하지 않는다고 말하고 싶지 않습니까?
이것이 가장 빠른 해결책이라고 자신합니다.
컨볼루션을 이동해 보겠습니다.

당신 뒤에, 니콜라스.

Union으로 변형을 제안했지만 예를 보여주지 않았습니다. 그런 다음 CharArrayToString 및 StringToCharArray 로 전환했습니다. 이제 다시 노조에 대해 이야기하고 있습니다.

즉, 문자열을 매력으로 만든 다음 다시 문자열을 깨고(문자열에는 매개변수 번호와 해당 값의 집합이 포함됨) 이것이 최상의 솔루션입니까?

 
관심을 위해 통합 옵션을 사용해 보겠습니다. 그리고 CharArrayToString 및 StringToCharArray 를 사용합니다. 그러나 내 본능은 그것이 MT-객체에 대한 설명을 통한 통신보다 빠르지 않을 것이라고 말합니다. 하지만, 내가 틀릴 수도 있습니다. 우리는 볼 것입니다 ...
 
Реter Konow :

당신 뒤에, 니콜라스.

나는 당신의 일을 망치고 싶지 않습니다. 본인이 직접 하는 것이 중요합니다. 그렇지 않으면 이해하지 못할 것입니다.
Peter, 문자열을 사용하여 double, long 및 int도 전송합니까?
 
Nikolai Semko :
Peter, 문자열을 사용하여 double, long 및 int도 전송합니까?

매개변수 커널은 단일 배열입니다. 그리고 그것은 string 유형 입니다. 한 가지 이유는 제네릭 유형입니다. 매우 편안합니다. 임의의 값을 기록한 다음 원하는 유형으로 이끕니다.

그렇지 않으면 많은 매개변수 커널을 만들어야 합니다. 각각의 값 유형에 대해. 결과적으로 매개변수 소유권, 인덱싱, 기록 위치 등에 혼동이 있을 수 있습니다.

 
Nikolai Semko :
당신의 일을 망치고 싶지 않습니다. 본인이 직접 하는 것이 중요합니다. 그렇지 않으면 이해하지 못할 것입니다.

트롤하지 맙시다. 멘토 톤이 적절하지 않습니다. 이 작품에서 나는 더 많이 이해합니다.


Nikolai, 나는 당신의 버전을 시도할 것이라고 말했습니다.)) 그래서 나는 시도할 것입니다.

 
Maxim Kuznetsov :

SQL을 사용하고 머리에 땀을 흘리지 마십시오 :-)

"당신의 두뇌를 엉망으로 만들지 마십시오"에 대해 계속되는 것처럼 :-)

오늘 나는 친절하고 전혀 악하지 않습니다 ..

Peter는 "비주얼 프로그래밍"(단순한 GUI가 아님)에 대해 개발을 위해 array-on-array에 괴물이 발생하지 않도록,
예를 들어 Oracle을 참조하십시오. 의심의 여지가 없는 지도자 중 한 명

비주얼 편집기는 무료( 가상 머신 과 함께)입니다. https://apex.oracle.com/en/

시작하려면 "인형을 위한 SQL 시작" 범주의 책과 며칠의 자유 시간이면 충분합니다.

Home
  • apex.oracle.com
Oracle APEX makes it easy to build beautiful apps that are responsive, accessible, and can be effortlessly customized to fit your company's brand and personality. The apps you build are responsive out-of-the-box and are designed to work well regardless of screen size or form factor. Our comprehensive set of modern UI components are all built to...
 
Реter Konow :

트롤하지 맙시다. 멘토 어조가 적절하지 않습니다. 이 작품에서 나는 더 많이 이해합니다.

나는 이것에 대해 당신을 설득할 목적이 없습니다.
나는 그런 톤이 아니었다. 당신이 그것을 배우고 더 빠른 방법을 적용할 수 있기를 바라며 당신보다 훨씬 더 빠른 코드를 여러 번 게시했지만 당신은 그것을 이용하지 않았습니다.

내가 왜 감사하지 않은 일을 해야 합니까?
 
Реter Konow :

매개변수 커널은 단일 배열입니다. 그리고 그것은 string 유형 입니다. 한 가지 이유는 제네릭 유형입니다. 매우 편안합니다. 임의의 값을 기록한 다음 원하는 유형으로 이끕니다.

그렇지 않으면 많은 매개변수 커널을 만들어야 합니다. 각각의 값 유형에 대해. 결과적으로 매개변수 소유권, 인덱싱, 기록 위치 등에 혼동이 있을 수 있습니다.

다양성은 종종 느림과 동의어이며 가죽 끈의 경우에는 더욱 그렇습니다.
한 가지 예를 들겠습니다.

한 번 WebRequest를 사용하여 암호화 교환에서 받은 문자열을 구문 분석하고 있었습니다. 그리고 그는 "고속 C++ 라이브러리"에서 자신이 이식한 Sergeev JSON 라이브러리 를 통해 구문 분석을 수행했습니다. 그리고 나는 속도가 어쩐지 매우 불만족스럽다는 것을 알아차렸다. 모든 것이 "보편적인" 라인을 통해 수행되었습니다.

속도가 느린 이유가 문자열이라는 것을 깨달았고 문자열 함수를 사용하지 않으려고 uchar 배열에서 직접 파싱 함수를 작성했습니다. 결과는 나를 많이 놀라게 했다. 내 파싱 속도는.... (drumroll) 800배 빨랐습니다. JSON을 통해 전체 문자열을 구문 분석하는 데 0.3초가 걸렸다면 내 함수를 통해 0.5밀리초 미만이 소요되었습니다.

다음 은 uchar 배열을 통한 구문 분석의 예입니다.

 
Nikolai Semko :

다재다능함은 종종 느림과 동의어이며 가죽 끈의 경우에는 더욱 그렇습니다.
한 가지 예를 들겠습니다.

한 번 WebRequest를 사용하여 암호화 교환에서 받은 문자열을 구문 분석하고 있었습니다. 그리고 그는 "고속 C++ 라이브러리"에서 자신이 이식한 Sergeev JSON 라이브러리 를 통해 구문 분석을 수행했습니다. 그리고 나는 속도가 어쩐지 매우 불만족스럽다는 것을 알아차렸다. 모든 것이 "보편적인" 라인을 통해 수행되었습니다.

문자열에서 벗어나고 싶었고 uchar 배열에서 직접 구문 분석 기능을 작성했습니다. 결과는 나를 많이 놀라게 했다. 내 파싱 속도는.... (drumroll) 800배 더 빨랐습니다.

다음 은 uchar 배열을 통한 구문 분석의 예입니다.

json 파싱(및 일반적으로 파싱)은 별개의 이야기입니다 ;-)

암호화와 함께 작동하는 매우 큰 단일 스레드 스크립트 응용 프로그램에 문제가 있습니다.
의심이 도처에 떨어졌고 모든 것이 최적화되지 않았습니다. 매복은 타사 json 파서에 있는 것으로 판명되었습니다 :-)

"보편적인" 라이브러리가 보편성을 위해 날카로워지고 가장 복잡한 json으로 작동하지만 우리 지역에는 그러한 라이브러리가 없습니다.
예, 모든 소포는 매우 짧습니다.

그리고 예, MQL의 텍스트 구문 분석은 여전히 즐거운 일입니다 :-) 글쎄, 이것은 텍스트 처리를 위한 것이 아닙니다. 내 말은, 당신은 할 수 있지만 그것은 @oops..

배열, 주문 - 이것은 MQL의 경로입니다.