test1은 첫 번째 호출에서 모든 요소를 한 번에 생성하고 ArrayResize에 대한 나머지 호출은 "유휴" 상태가 됩니다. ArrayResize == array_size에 대한 총 호출 수:
T class_array[];
for ( int i = 1 ; i <= array_size; i++){
ArrayResize (class_array, array_size);
}
test2는 하나의 요소를 생성하고 다른 array_size-1 요소를 위한 공간을 예약합니다. 나머지 ArrayResize 호출은 이전에 예약된 메모리에서 배열에 +1 요소를 생성하기 위해 이동합니다. ArrayResize == array_size에 대한 총 호출 수:
T class_array[];
ArrayResize (class_array, 1 , array_size - 1 );
for ( int i = 2; i <= array_size; i++){
ArrayResize (class_array, i);
}
* 원본 코드에 오류가 있었습니다(차이 +- 하나의 요소). 코드가 업데이트되었습니다. 질문은 여전히 열려 있습니다. 왜 test2 알고리즘이 구조의 경우 test1보다 7배 느리고 class 및 int의 경우 2배 느린가요?
내 입장에서는 무엇을 비교했어야 했는가. 배열에 얼마나 많은 요소가 배치될지 알고 있으며 한 번에 모두 생성하는 대신 생성되지 않은 요소를 위한 메모리를 예약합니다. 문제는 메모리를 예약하고 배열 요소 를 한 번에 하나씩 만들면 모든 것을 한 번에 만드는 것보다 몇 배나 더 많은 시간이 걸린다는 것입니다. 따라서 구조의 경우 - 7배 느립니다. 그리고 데이터 유형의 경우 class와 int는 두 배 느립니다.
이것은 매우 큰 차이로, 원할 경우 개발자가 제거할 수 있는 것 같습니다.
그런 경우에는 더 적은 오버헤드만 있어야 한다는 데 동의합니다.
그러나 제 생각에는 문제는 오히려 당신이 비교하는 방법에 있습니다. test1의 루프는 컴파일러에 의해 최적화되고 제거될 가능성이 높으며 다음과 같은 경우도 있습니다.
위의 코드 #26666 을 디버그 모드에서 실행하면 브레이크가 사용자 코드 최적화가 아닌 ArrayResize 함수의 작업에 있기 때문에 이전에 얻은 것과 유사한 결과를 볼 수 있습니다. 디버그 모드는 최적화 없이 실행됩니다. 코드에 작성된 내용이 실행되고 사용자 지정 중단점에 대한 nop만 명령어 사이에 삽입됩니다.
위의 코드 #26666 을 디버그 모드에서 실행하면 브레이크가 사용자 코드 최적화가 아닌 ArrayResize 함수의 작업에 있기 때문에 이전에 얻은 것과 유사한 결과를 볼 수 있습니다. 디버그 모드는 최적화 없이 실행됩니다. 코드에 작성된 내용이 실행되고 사용자 지정 중단점에 대한 nop만 명령어 사이에 삽입됩니다.
게시물 #26674 에서 볼 수 있듯이 ArrayResize()에는 문제가 없지만 벤치마킹에만 문제가 있습니다. 내가 놓친 것이 없다면.
문제는 메모리를 예약하고 배열 요소 를 한 번에 하나씩 만들면 모든 것을 한 번에 만드는 것 보다 몇 배나 더 많은 시간이 걸린다는 것입니다.
코드에서 눈치채지 못했습니다. 그러면 이해할 수 있기 때문에 작동하는 경우 하나만 있고 크기가 변경되지 않은 경우 종료합니다.
코드에서 눈치채지 못했습니다. 그러면 이해할 수 있기 때문에 작동하는 경우 하나만 있고 크기가 변경되지 않은 경우 종료합니다.
위 코드 #26666 에 대한 설명
test1은 첫 번째 호출에서 모든 요소를 한 번에 생성하고 ArrayResize에 대한 나머지 호출은 "유휴" 상태가 됩니다.
ArrayResize == array_size에 대한 총 호출 수:
test2는 하나의 요소를 생성하고 다른 array_size-1 요소를 위한 공간을 예약합니다. 나머지 ArrayResize 호출은 이전에 예약된 메모리에서 배열에 +1 요소를 생성하기 위해 이동합니다.
ArrayResize == array_size에 대한 총 호출 수:
* 원본 코드에 오류가 있었습니다(차이 +- 하나의 요소). 코드가 업데이트되었습니다.
질문은 여전히 열려 있습니다. 왜 test2 알고리즘이 구조의 경우 test1보다 7배 느리고 class 및 int의 경우 2배 느린가요?
내 입장에서는 무엇을 비교했어야 했는가.
배열에 얼마나 많은 요소가 배치될지 알고 있으며 한 번에 모두 생성하는 대신 생성되지 않은 요소를 위한 메모리를 예약합니다.
문제는 메모리를 예약하고 배열 요소 를 한 번에 하나씩 만들면 모든 것을 한 번에 만드는 것보다 몇 배나 더 많은 시간이 걸린다는 것입니다.
따라서 구조의 경우 - 7배 느립니다.
그리고 데이터 유형의 경우 class와 int는 두 배 느립니다.
이것은 매우 큰 차이로, 원할 경우 개발자가 제거할 수 있는 것 같습니다.
그런 경우에는 더 적은 오버헤드만 있어야 한다는 데 동의합니다.
그러나 제 생각에는 문제는 오히려 당신이 비교하는 방법에 있습니다. test1의 루프는 컴파일러에 의해 최적화되고 제거될 가능성이 높으며 다음과 같은 경우도 있습니다.
프로파일러를 사용해 보면 작은 차이만 보일 것입니다.
프로파일러 를 사용한 컴파일러 최적화가 없습니다.
질문은 여전히 열려 있습니다. 왜 test2 알고리즘이 구조의 경우 test1보다 7배 느리고 class 및 int의 경우 2배 느린가요?
기본 생성자.
test1의 루프는 컴파일러에 의해 최적화되고 제거되었을 가능성이 큽니다.
위의 코드 #26666 을 디버그 모드에서 실행하면 브레이크가 사용자 코드 최적화가 아닌 ArrayResize 함수의 작업에 있기 때문에 이전에 얻은 것과 유사한 결과를 볼 수 있습니다.
디버그 모드는 최적화 없이 실행됩니다. 코드에 작성된 내용이 실행되고 사용자 지정 중단점에 대한 nop만 명령어 사이에 삽입됩니다.
새 서비스의 SMS는 SMS를 통한 데모 계정 개설 확인에 도달하지 않습니다. 여기 더.
https://www.mql5.com/en/forum/334179#comment_1529250
위의 코드 #26666 을 디버그 모드에서 실행하면 브레이크가 사용자 코드 최적화가 아닌 ArrayResize 함수의 작업에 있기 때문에 이전에 얻은 것과 유사한 결과를 볼 수 있습니다.
디버그 모드는 최적화 없이 실행됩니다. 코드에 작성된 내용이 실행되고 사용자 지정 중단점에 대한 nop만 명령어 사이에 삽입됩니다.
게시물 #26674 에서 볼 수 있듯이 ArrayResize()에는 문제가 없지만 벤치마킹에만 문제가 있습니다. 내가 놓친 것이 없다면.
vector<T>::push_back 알고리즘에 대한 병목 현상을 검색하던 중 실제 프로젝트에서 문제가 발견되었습니다.
문제는 릴리스 및 디버그 컴파일 모두에서 예약된 메모리가 있는 상태에서 ArrayResize의 느린 실행의 일부로 나타납니다.
프로파일링에서 아무 것도 찾지 못했기 때문에 모든 것이 정상이라고 말합니다.
결과에 반대하는 사람은 없습니다.
그러나 프로파일링 중 문제의 가시성이 부족하다고 해서 100% 사용자가 사용하는 릴리스 및 디버그 컴파일에서 문제의 존재가 무효화되는 것은 아닙니다.
vector<T>::push_back 알고리즘에 대한 병목 현상을 검색하던 중 실제 프로젝트에서 문제가 발견되었습니다.
문제는 릴리스 및 디버그 컴파일 모두에서 예약된 메모리가 있는 상태에서 ArrayResize의 느린 실행의 일부로 나타납니다.
프로파일링에서 아무 것도 찾지 못했기 때문에 모든 것이 정상이라고 말합니다.
결과에 반대하는 사람은 없습니다.
그러나 프로파일링 중 문제의 가시성이 부족하다고 해서 100% 사용자가 사용하는 릴리스 및 디버그 컴파일에서 문제의 존재가 무효화되는 것은 아닙니다.
나는 당신이 제공한 테스트 코드에 대해서만 말할 수 있습니다.
어쨌든 우리는 개발자들이 말하는 것을 보게 될 것입니다. 아마도.