다재다능함은 종종 느림과 동의어이며 가죽 끈의 경우에는 더욱 그렇습니다. 한 가지 예를 들겠습니다.
한 번 WebRequest를 사용하여 암호화 교환에서 받은 문자열을 구문 분석하고 있었습니다. 그리고 그는 "고속 C++ 라이브러리"에서 자신이 이식한 Sergeev JSON 라이브러리 를 통해 구문 분석을 수행했습니다. 그리고 나는 속도가 어쩐지 매우 불만족스럽다는 것을 알아차렸다. 모든 것이 "보편적인" 라인을 통해 수행되었습니다.
속도가 느린 이유가 문자열이라는 것을 깨달았고 문자열 함수를 사용하지 않으려고 uchar 배열에서 직접 파싱 함수를 작성했습니다. 결과는 나를 많이 놀라게 했다. 내 파싱 속도는.... (drumroll) 800배 더 빨랐습니다. JSON을 통해 전체 문자열을 구문 분석하는 데 0.3초가 걸렸다면 내 함수를 통해 0.5밀리초 미만이 소요되었습니다.
두 번째 배열에 ResourceReadImage()를 사용하여 두 번째 측면의 리소스 내용을 가져옵니다.
두 번째 배열을 CharArrayToString()에 보내고 최종 문자열을 얻습니다.
다음으로 문자열을 구분 기호로 분할하고 매개 변수 값을 커널에 씁니다.
원래 MT 개체를 사용하여 문자열을 전달하고 싶었습니다.
문자열(640자)을 가져와서 각각 64자의 부분으로 나눕니다.
연결 개체를 반복하고 설명에 문자열의 일부를 씁니다.
두 번째 측면에서 연결 개체를 반복하고 문자열의 일부를 가져오고 각 부분을 구분 기호로 분할하여 매개 변수 번호와 값을 추출합니다.
커널에 매개변수 값을 씁니다.
처음에는 두 번째 옵션이 더 빠르다고 생각했습니다.
나만큼 많은 문제를 가지고 작업할 때 솔루션을 선택할 때 직관에 의존해야 합니다. 인생은 모든 것을 철저히 확인하기에 충분하지 않습니다. 결정의 방향을 선택할 때 팀이나 탁월한 본능이 필요합니다. 물론 전문성을 희생하고 지식의 격차를 감수해야 합니다. 그렇지 않으면 공예품을 더듬거리며 (전문적으로는 무리가 있음에도 불구하고) 메가 프로젝트를 끝내지 못할 것입니다. 이것은 현실입니다.
Реter Konow : 관심을 위해 통합 옵션을 사용해 보겠습니다. 그리고 CharArrayToString 및 StringToCharArray를 사용합니다. 그러나 내 본능은 그것이 MT-객체에 대한 설명을 통한 통신보다 빠르지 않을 것이라고 말합니다. 하지만, 내가 틀릴 수도 있습니다. 우리는 볼 것입니다 ...
Peter, 당신은 처음에 게임을 만들었고 지금은 게임 내 메시징 성능에 대해 이야기하고 있습니다. 문자열은 단지 편리한 ***일 뿐이며 그 이상은 아닙니다. 모든 데이터는 실제로 메모리의 바이트 모음입니다. 따라서 바이트열로 직접 작업하는 것이 좋으며 항상 그렇듯이 고집이 세서 동일한 문자열이 동일한 바이트 배열이라는 사실을 깨닫지 못합니다. 따라서 문자열을 uchar 배열로 변환해도 아무 것도 잃지 않지만 문자열을 구문 분석할 때 성능이 실제로 저하됩니다. 따라서 모든 직관은 일반적으로 과거입니다.
1. Peter, 당신은 처음에 게임을 만들었고, 지금 당신은 게임 내에서 메시징의 성능에 대해 이야기하고 있습니다.
2. 당신은 이해합니다: 문자열은 단지 편리한 ***, 그 이상입니다. 모든 데이터는 실제로 메모리의 바이트 모음입니다. 따라서 바이트열로 직접 작업하는 것이 좋으며 항상 그렇듯이 고집이 세서 동일한 문자열이 동일한 바이트 배열이라는 사실을 깨닫지 못합니다. 따라서 문자열을 uchar 배열로 변환해도 아무 것도 잃지 않지만 문자열을 구문 분석할 때 성능이 실제로 저하됩니다.
3. 따라서 모든 직관은 일반적으로 과거입니다.
1. "게임" - 이 경우 이것은 내가 한 것이 아니라 귀하의 이해입니다. 그것이 무엇에 관한 것이고 엔진이 무엇인지 이해하는 데 75페이지 가 걸렸습니다. 이해하십시오: 결함과 오류는 본질을 특징짓지 않습니다. 어떤 형태의 본질도 본질 자체를 특징짓지 않습니다 . 옷차림이 당신이 어떤 사람인지를 정의하는 것은 아닙니다. 잘못된 생각만이 전체를 개별적으로 판단합니다.
2. 이것은 이미 나에게 분명합니다. StringToChar 기능을 사용하면 실제로 속도가 향상되는지 오늘 확인하겠습니다.
3. 나는 매일 내 직감을 확인한다. 나는 매일 그것을 의심한다. 그리고 맞습니다. 실패하면 Reason의 안내를 받아야 합니다. 그러나 이성은 항상 의지하기에는 너무 제한적이고 오만하고 어리석습니다. 그러므로 직관만이 유일한 대안이다. 제 말을 이해하셨다면...
그리고 예, MQL의 텍스트 구문 분석은 여전히 즐거운 일입니다 :-) 글쎄, 이것은 텍스트 처리를 위한 것이 아닙니다. 내 말은, 할 수 있지만 그건 @oops..
배열, 주문 - 이것은 MQL의 경로입니다.
그게 바로 우리가 이야기하는 것입니다... :)
다재다능함은 종종 느림과 동의어이며 가죽 끈의 경우에는 더욱 그렇습니다.
한 가지 예를 들겠습니다.
한 번 WebRequest를 사용하여 암호화 교환에서 받은 문자열을 구문 분석하고 있었습니다. 그리고 그는 "고속 C++ 라이브러리"에서 자신이 이식한 Sergeev JSON 라이브러리 를 통해 구문 분석을 수행했습니다. 그리고 나는 속도가 어쩐지 매우 불만족스럽다는 것을 알아차렸다. 모든 것이 "보편적인" 라인을 통해 수행되었습니다.
속도가 느린 이유가 문자열이라는 것을 깨달았고 문자열 함수를 사용하지 않으려고 uchar 배열에서 직접 파싱 함수를 작성했습니다. 결과는 나를 많이 놀라게 했다. 내 파싱 속도는.... (drumroll) 800배 더 빨랐습니다. JSON을 통해 전체 문자열을 구문 분석하는 데 0.3초가 걸렸다면 내 함수를 통해 0.5밀리초 미만이 소요되었습니다.
다음 은 uchar 배열을 통한 구문 분석의 예입니다.
제안의 요지는 다음과 같습니다.
원래 MT 개체를 사용하여 문자열을 전달하고 싶었습니다.
처음에는 두 번째 옵션이 더 빠르다고 생각했습니다.
나만큼 많은 문제를 가지고 작업할 때 솔루션을 선택할 때 직관에 의존해야 합니다. 인생은 모든 것을 철저히 확인하기에 충분하지 않습니다. 결정의 방향을 선택할 때 팀이나 탁월한 본능이 필요합니다. 물론 전문성을 희생하고 지식의 격차를 감수해야 합니다. 그렇지 않으면 공예품을 더듬거리며 (전문적으로는 무리가 있음에도 불구하고) 메가 프로젝트를 끝내지 못할 것입니다. 이것은 현실입니다.
제안의 요지는 다음과 같습니다.
별말씀을요.
바쁜 동안 - 설명할 시간이 없습니다.
내 코드 를 자세히 분석하여 흰 점이 남지 않게 하면 스스로 많은 것을 발견하게 될 것입니다.
추신. 디버거를 사용하지 않고서는 그것을 알아내기가 훨씬 더 어려울 것입니다. 사용하기 시작했는지 아니면 이 중요한 도구를 아직 사용하지 않는지 모르겠습니다.
...
내 코드 를 자세히 분석하여 흰 점이 남지 않게 하면 스스로 많은 것을 발견하게 될 것입니다.
추신. 디버거를 사용하지 않고서는 그것을 알아내기가 훨씬 더 어려울 것입니다. 사용하기 시작했는지 아니면 이 중요한 도구를 아직 사용하지 않는지 모르겠습니다.
내일 코드를 자세히 살펴보겠습니다. (시간대를 잊지 마세요)
아마도 나는 나 자신을 위해 새로운 것을 발견할 것입니다. ))
모든 구조는 문자열입니다. 구조 배열은 형식에 대한 설명이 있는 문자열 배열입니다. 클래스는 구조와 메서드이고 클래스 구현은 구현의 배열입니다(내 프랑스어를 용서하십시오).
마지막 순간까지 아무것도 변환할 필요가 없습니다. 여기에는 문자열만 포함됩니다. 간단히 말해서 정규화됩니다. 누군가는 2 또는 4바이트를 사용하고 누군가는 1이므로 정렬해야 합니다.
ZY 약 1993년에 Clarion DBMS에서 이 접근 방식을 처음 적용했습니다. 모든 것이 매우 빠르게 작동했습니다.
모든 구조는 문자열입니다. 구조 배열은 형식에 대한 설명이 있는 문자열 배열입니다. 클래스는 구조와 메서드이고 클래스 구현은 구현의 배열입니다(내 프랑스어를 용서하십시오).
마지막 순간까지 아무것도 변환할 필요가 없습니다. 여기에는 문자열만 포함됩니다. 간단히 말해서 정규화됩니다. 누군가는 2 또는 4바이트를 사용하고 누군가는 1이므로 정렬해야 합니다.
ZY 대략 1993년에 이 접근 방식을 처음 적용한 Clarion DBMS . 모든 것이 매우 빠르게 작동했습니다.
거의 동시에 같은 시간에 :-) 한 학교... 그건 그렇고, DBMS는 나쁘지 않았고 여러 면에서 시대를 앞서갔습니다.
PS/는 "모든 것이 선/텍스트다"라는 개념의 수준에서 가장 좋아하는 간지럼입니다. 진정한 파이썬 속도
내일 코드를 자세히 살펴보겠습니다. (시간대를 잊지 마세요)
아마도 나는 나 자신을 위해 새로운 것을 발견할 것입니다. ))
아마도 이것은 여전히 유용합니다
TF를 변경할 때 값을 다시 초기화하지 않는 double의 예에서 자원 변수를 사용하는 표시기의 예입니다. 터미널 전역 변수 에 대한 보다 편리한 대안입니다. 전역과 같은 방식으로 다양한 데이터 구조와 이러한 구조의 배열을 사용할 수 있습니다.
아마도 이것은 여전히 유용합니다
)
관심을 위해 통합 옵션을 사용해 보겠습니다. 그리고 CharArrayToString 및 StringToCharArray를 사용합니다. 그러나 내 본능은 그것이 MT-객체에 대한 설명을 통한 통신보다 빠르지 않을 것이라고 말합니다. 하지만, 내가 틀릴 수도 있습니다. 우리는 볼 것입니다 ...
Peter, 당신은 처음에 게임을 만들었고 지금은 게임 내 메시징 성능에 대해 이야기하고 있습니다. 문자열은 단지 편리한 ***일 뿐이며 그 이상은 아닙니다. 모든 데이터는 실제로 메모리의 바이트 모음입니다. 따라서 바이트열로 직접 작업하는 것이 좋으며 항상 그렇듯이 고집이 세서 동일한 문자열이 동일한 바이트 배열이라는 사실을 깨닫지 못합니다. 따라서 문자열을 uchar 배열로 변환해도 아무 것도 잃지 않지만 문자열을 구문 분석할 때 성능이 실제로 저하됩니다. 따라서 모든 직관은 일반적으로 과거입니다.
1. Peter, 당신은 처음에 게임을 만들었고, 지금 당신은 게임 내에서 메시징의 성능에 대해 이야기하고 있습니다.
2. 당신은 이해합니다: 문자열은 단지 편리한 ***, 그 이상입니다. 모든 데이터는 실제로 메모리의 바이트 모음입니다. 따라서 바이트열로 직접 작업하는 것이 좋으며 항상 그렇듯이 고집이 세서 동일한 문자열이 동일한 바이트 배열이라는 사실을 깨닫지 못합니다. 따라서 문자열을 uchar 배열로 변환해도 아무 것도 잃지 않지만 문자열을 구문 분석할 때 성능이 실제로 저하됩니다.
3. 따라서 모든 직관은 일반적으로 과거입니다.
1. "게임" - 이 경우 이것은 내가 한 것이 아니라 귀하의 이해입니다. 그것이 무엇에 관한 것이고 엔진이 무엇인지 이해하는 데 75페이지 가 걸렸습니다. 이해하십시오: 결함과 오류는 본질을 특징짓지 않습니다. 어떤 형태의 본질도 본질 자체를 특징짓지 않습니다 . 옷차림이 당신이 어떤 사람인지를 정의하는 것은 아닙니다. 잘못된 생각만이 전체를 개별적으로 판단합니다.
2. 이것은 이미 나에게 분명합니다. StringToChar 기능을 사용하면 실제로 속도가 향상되는지 오늘 확인하겠습니다.
3. 나는 매일 내 직감을 확인한다. 나는 매일 그것을 의심한다. 그리고 맞습니다. 실패하면 Reason의 안내를 받아야 합니다. 그러나 이성은 항상 의지하기에는 너무 제한적이고 오만하고 어리석습니다. 그러므로 직관만이 유일한 대안이다. 제 말을 이해하셨다면...