Using Zeno’s Paradox For Progress Bars

ProgressBar를 만드는데 필요한 두가지 요소는 전체 작업의 양, 현재까지 진행된 작업의 양 이렇게 두가지입니다. 그러면 ProgressBar는 보통

total = 100
for (current = 0; ...; ++current)
{
   doWork();
   updateProgressBar(total, current);
}
updateProgressBar(total, total);

와 같이 쓸 수 있죠. 문제는 이렇게 하려면 최초에 total값을 알아야 한다는 것입니다. 만약 파일을 열어서 한줄씩 처리하는거라면 일단 파일내 전체 행의 개수를 사전에 total에 넣을 것이고, 만약 DB를 읽어서 레코드를 하나씩 처리하는거라면 또 전체 레코드의 수를 미리 구해야합니다. 그리고 이 두가지 동작모두 비용이 매우 많이 들 때가 있습니다.

위 링크는 이런 경우에 어떻게 해결할까..라는 질문에 대한답입니다. 세가지 방법이 있는데,

1) 일단 total=100으로 놓는다. current는 루프를 돌때마다 1증가.

2) 일단 total=100으로 놓는다. current가 total * 0.8 만큼 다가오면 total 을 2배 증가시킨다. (가변길이 배열이 반차면 크기 2배로 늘리듯이 한단 말입니다.)

3) 일단 total=100으로 놓는다. current가 total이 되면 total을 증가시킨다. 그 뒤, 이번에는 루프문 한번마다 current 가 1씩 증가되던것을, 1*p (p는 0초과 1미만의 부동소수)만큼 증가시킨다. 또 다시 current가 total이되면 total을 증가시키고, 루프마다 current 의 증가분을 1 * p * p로 한다.

3번째가 마치 제논의 역설과 유사하다고해서 링크의 제목이 위와 같이 되었습니다. 흥미로운 문제이고 저라면 2번을 쓰겠습니다. 2번은 total 이 매번 2배씩 증가되므로 예를들어 전체 일의양이 실제로는 150이었다면 나머지 50의 증가는 갑자기 점프하는 듯 하게 보일테지만, 그게 문제는 안되기 때문이죠. 한편 3번은 복잡해보이지만, 별다른 이득은 없어보입니다. 그리고 실제로 링크된 글의 코드도 완벽하지 않은 듯.

물론 정확한 방법을 생각할 수야 있겠지만, 그로인한 소득은 매우 작아보입니다. 실제로 현대의 거의 모든 소프트웨어의 인스톨시에 보이는 progress bar들은 갑자기 바가 점프하거나 갑자기 느리게 가는 등 역시 대강철저히 코딩되었음을 확인할 수 있습니다.