진행 막대가 왜 그렇게 부정확합니까?

처음에는 정확한 시간 추정을 생성하는 것이 매우 쉬워야하는 것으로 보입니다. 결국 진행률 막대를 생성하는 알고리즘은 미리 수행해야하는 모든 작업을 알고 있습니다.?

대부분의 경우, 소스 알고리즘이 미리 수행해야 할 작업을 알고 있다는 것이 사실입니다. 그러나 각 단계를 수행하는 데 걸리는 시간을 고정하는 것은 사실상 불가능하지는 않지만 매우 어렵습니다..

모든 작업이 같지 않음

진행률 막대를 구현하는 가장 간단한 방법은 작업 카운터의 그래픽 표현을 사용하는 것입니다. 완료율은 다음과 같이 간단히 계산됩니다. 완료된 작업 / 총 작업 수. 이것이 처음 생각할 때 논리적 인 의미를 가지지 만, (명백하게) 일부 작업은 완료하는 데 더 오래 걸리는 것을 기억하는 것이 중요합니다.

설치 관리자가 수행하는 다음 작업을 고려하십시오.

폴더 구조 만들기.
1GB 상당의 파일 압축 풀기 및 복사.
레지스트리 항목 만들기.
시작 메뉴 항목 만들기.

이 예제에서 1, 3, 4 단계는 매우 빨리 완료되지만 2 단계는 약간의 시간이 소요됩니다. 따라서 간단한 계산을하는 진행률 표시 줄은 매우 빠르게 25 %로 점프하고, 2 단계가 작동하는 동안 조금씩 실속 한 다음 거의 즉시 100 %로 점프합니다.

위에서 언급했듯이 구현하기가 쉽기 때문에 이러한 유형의 구현은 실제로 진행 막대간에 매우 일반적입니다. 그러나 볼 수 있듯이, 불균형 한 작업이 발생할 수 있습니다. 실제의 남은 시간과 관련된 진행률.

이 문제를 해결하기 위해 일부 진행률 막대에서는 단계에 가중치가 적용되는 구현을 사용할 수 있습니다. 각 단계에 상대적 가중치가 지정된 위의 단계를 고려하십시오.

폴더 구조를 만듭니다. [무게 = 1]
압축을 풀고 1GB 상당의 파일을 복사하십시오. [무게 = 7]
레지스트리 항목을 만듭니다. [무게 = 1]
시작 메뉴 항목을 만듭니다. [무게 = 1]

이 방법을 사용하면 진행률 막대가 10 % 씩 증가하고 (총 무게가 10이므로) 1, 3, 4 단계에서 막대가 완료되면 10 %, 2 단계에서는 70 % 이동합니다. 확실히 완벽하지는 않지만 이와 같은 방법은 진행률 막대의 백분율을 약간 더 정확하게 추가하는 간단한 방법입니다.

과거 실적이 미래 실적을 보장하지 않음

스톱워치를 사용하는 동안 50으로 계산하도록 요청하는 간단한 예를 생각해보십시오. 10 초 안에 25로 계산됩니다. 나머지 10 초 동안 나머지 수를 계산한다고 가정하는 것이 합리적입니다. 따라서이를 추적하는 진행률 표시 줄에 10 초 남았을 때 50 %가 완료 될 것입니다.

그러나 당신의 카운트가 25에 도달하면, 나는 당신에게 테니스 공을 던지기 시작합니다. 아마도, 집중력이 숫자를 엄밀히 세는 것에서 자신의 방식으로 던진 공을 피하는 것으로 옮겨 가면서 리듬을 깨뜨릴 것입니다. 카운팅을 계속할 수 있다고 가정하면 속도가 확실히 느려집니다. 이제 진행률 표시 줄은 여전히 움직이고 있지만 예상 속도가 훨씬 느린 속도로 정지하거나 실제로 올라갈 때까지 남아 있습니다..

이에 대한보다 실질적인 예를 보려면 파일 다운로드를 고려하십시오. 현재 100MB 파일을 1MB / s 속도로 다운로드 중입니다. 이것은 예상 완료 시간을 결정하기가 매우 쉽습니다. 하지만 거기에 75 %, 일부 네트워크 정체 및 다운로드 속도가 500KB / s로 떨어집니다.

브라우저가 남은 시간을 계산하는 방법에 따라 ETA가 즉시 25 초에서 50 초로 갈 수 있습니다 (현재 상태 만 사용 : 남아있는 크기 / 다운로드 속도) 또는 브라우저가 사용자에게 극적인 점프를 표시하지 않고 전송 속도의 변동을 조정하는 롤링 평균 알고리즘을 사용합니다.

파일 다운로드와 관련된 롤링 알고리즘의 예는 다음과 같이 작동 할 수 있습니다.

이전 60 초 동안의 전송 속도는 가장 오래된 값을 대체하는 가장 새로운 값으로 기억됩니다 (예 : 61 번째 값이 첫 번째 값을 대체 함).
계산 목적의 유효 전송률은 이러한 측정의 평균입니다.
남은 시간은 다음과 같이 계산됩니다. 남아있는 크기 / 효과적인 다운로드 속도

위의 시나리오를 사용하면 (단순화를 위해 1MB = 1,000KB를 사용합니다).

다운로드 75 초에 기억 된 60 개의 값은 각각 1,000KB가됩니다. 유효 전송률은 1,000KB (60,000KB / 60)이며 남은 시간은 25 초 (25,000KB / 1,000KB)입니다..
전송 속도가 500KB로 떨어지는 76 초에서 유효 다운로드 속도는 약 992KB (59,500KB / 60)가되어 ~ 24.7 초 (24,500KB / 992KB) 남은 시간이됩니다..
77 초 : 유효 속도 = ~ 983KB (59,000KB / 60) ~ 24.4 초 남음 (24,000KB / 983KB).
78 초 : 유효 속도 = 975KB (58,500KB / 60) ~ 24.1 초 남음 (23,500KB / 975KB).

다운로드 속도의 저하가 남은 시간을 추정하는 데 사용되는 평균에 천천히 통합되므로 여기서 나타나는 패턴을 볼 수 있습니다. 이 방법에서 딥이 10 초 동안 지속 된 후 1MB / s로 돌아 가면 사용자는 차이를 알 수 없을 것입니다 (추정 된 시간 카운트 다운에서 매우 작은 실마리를 제외하고).

황동 압정에 도달하기 - 이것은 실제 근본 원인에 대한 정보를 최종 사용자에게 전달하는 단순한 방법론입니다 ...

너는 비결정론적인 것을 정확하게 결정할 수 없다.

궁극적으로 진행률 막대 부정확성은 비 결정적 인 무언가를위한 시간을 결정하려고한다는 사실로 귀결됩니다. 컴퓨터가 필요에 따라 백그라운드에서 작업을 처리하기 때문에 앞으로 어떤 시점에서 어떤 시스템 리소스를 사용할 수 있는지 알기가 거의 불가능하며 모든 작업을 완료하는 데 필요한 시스템 리소스를 사용할 수 있습니다.

다른 예제를 사용하여 상당히 집중적 인 데이터베이스 업데이트를 수행하는 서버에서 프로그램 업그레이드를 실행한다고 가정합니다. 이 업데이트 프로세스 중에 사용자는이 시스템에서 실행중인 다른 데이터베이스로 요청하는 요청을 보냅니다. 이제 데이터베이스를위한 서버 리소스가 업그레이드와 사용자 시작 쿼리 모두에 대한 요청을 처리해야합니다.이 시나리오는 확실히 실행 시간에 해를 끼칠 수 있습니다. 또는 사용자가 저장 처리량에 과도한 대용량 파일 전송 요청을 시작하여 성능을 저하시킬 수 있습니다. 또는 메모리 집약적 인 프로세스를 수행하는 예약 된 작업을 시작할 수도 있습니다. 당신은 아이디어를 얻는다..

매일 사용자를위한보다 현실적인 인스턴스 인 Windows Update 또는 바이러스 검사를 실행하는 것이 좋습니다. 이 두 작업 모두 백그라운드에서 리소스를 많이 사용하는 작업을 수행합니다. 결과적으로, 각각의 진행 상황은 사용자가 당시 수행중인 작업에 따라 다릅니다. 이것이 실행되는 동안 전자 메일을 읽는다면 시스템 리소스에 대한 요구가 낮아지고 진행률 표시 줄이 계속 움직일 것입니다. 반면에 그래픽 편집을하는 경우 시스템 리소스에 대한 요구가 훨씬 커져서 진행률 표시 줄이 정신 분열증으로 변하게됩니다.

전반적으로 단순히 크리스탈 볼이 없다는 것입니다. 시스템 자체조차도 미래 어느 시점에 어떤 부하가 걸릴지를 안다..

궁극적으로, 그것은 정말로 중요하지 않습니다.

진행률 표시 줄의 의도는 진행 상황이 실제로 만들어지고 해당 프로세스가 중단되지 않았 음을 나타냅니다. 진행률 표시기가 정확할 때 좋습니다. 그러나 일반적으로 진행률 표시기가 정확하지 않을 때 사소한 성가심 일뿐입니다. 대부분의 경우, 개발자는 진도 막대 알고리즘에 많은 시간과 노력을 투입하지 않을 것입니다. 솔직히 말해서, 시간을 낭비하는 훨씬 중요한 작업이 있기 때문입니다..

물론 진행률 표시 줄이 즉시 99 %로 점프 한 다음 남은 1 %를 5 분간 기다릴 때마다 당황 할 수있는 모든 권리가 있습니다. 그러나 각 프로그램이 전반적으로 잘 작동한다면 개발자에게 우선 순위가 있음을 상기시켜주십시오..