저는 현재 벽 시계 시간을 사용하여 다양한 결정을 내리는 알고리즘을 유지 관리하고 있습니다 (예 : 어떤 솔루션을 계산하기에는 너무 오래 걸리며 폐기해야 할 필요가 있음). 알고리즘을 테스트하려고 할 때벽 시계 시간 기반 알고리즘 테스트
는, 결과 등 기계 부하, 운영 체제 스케줄링, IO
이러한 시스템을 테스트하기위한 표준 방법은 무엇입니까 같은 변수의 수에 의한마다 다소 차이가있을 수 있습니까? 실행 된 CPU 명령어와 같은 것이 내가 가진 하나의 아이디어 였지만, 현재의 멀티 코어 x86 프로세서가 얼마나 실용적인지는 잘 모르겠습니다.
fallback 계획은 내부 카운터에 증가분을 추가하고 알고리즘의 한계를 변경하여 기존 벽시계 버전의 성능을 시도합니다. 그러나 많은 시행 착오를 거쳐야하므로 경로를 시작하기 전에 쉬운 방법이 있는지 알고 싶습니다.
단순하지만 유익한 옵션은 벽 시간 검색 로직을 "추상화"하는 것입니다.
WallTime을 GetTime 방법으로 사용하고이를 응용 프로그램 전체에서 사용하십시오.
이 클래스에서 사용할 수있는 시간의 두 가지 공급자가 있습니다. 하나는 시스템의 RT 클럭입니다.
기타는 단순히 미리 녹음 된 목록에서 값을 반환합니다.
알고리즘을 통해 첫 번째 패스를 기록하고 GetTime에 의해 반환 된 값을 저장합니다. 이 값은 두 번째 "시간 제공자"에 대한 값의 "사전 기록 된"목록을 형성합니다. 당신은 단순히 당신이 어떤 타이밍을 조정하려면 당신은 또한 목록을 편집 할 수
첫 번째 실행 :에서와 동일한 시간 값을 반환 할 수 있습니다 동일한 순서로 GetTime에 전화를 할 것입니다 두 번째 실행을 가정
. 다른 하드웨어를 시뮬레이트하기 위해 여러 저장된 목록을 가질 수도 있습니다.
예 :
알고리즘은 다음과 같이 작동한다고 가정
이GetTime -> 시계GetTime이 함수 X에서 T1을 반환 Y).
GetTime -> 시계YGetTime ->당신이에서 T1, T2, T3와 T4를 저장 한 후 ... 시계 에서 T4를 반환 목록에서 정확히 위의 실행을 재생할 수 있습니다 (GetTime에 의해 반환 된 값과 관련하여).
(T2 - T1) 시차가 같더라도 6 단계에서 실행 한 함수 (알고리즘이 성능에 따라 선택하는 함수)가 두 번째 실행에서 동일하지 않으면이 솔루션이 실패합니다 즉, 변수가 아닌 시간 관련 매개 변수에 따라 달라집니다.
@ Andrei의 솔루션이 마음에 들지만, 알고리즘이 항상 같은 순서로 타이밍 호출을하는 것은 아닙니다. 이 경우 이름/열거 형 (startTimerFor(SOME_KEY) 및 getElapsedTimeFor(SOME_KEY)과 같은 메서드 사용)으로 다양한 기간을 기록 할 수있는 간단한 WallClockTimer 클래스를 만들 수 있습니다. 알고리즘은이 타이머와 협력하여 런타임 결정을 내립니다. 이러한 결정을 테스트하려면 MockWallClockTimer을 지정된 키에 대해 미리 지정된 기간을 반환하도록 만들 수 있습니다.