브라우저에서 타이머(setTimeout 또는 setInterval)를 사용해 함수를 호출하도록 할때, 다음과 같이 호출될 함수와 호출될 시간을 밀리세컨드로 지정한다.
setTimeout(function() { ... }, nTimeMS);
setInterval(function() { ... }, nTimeMS);
그런데, 보통은 타이머에 지정한 시간대로 호출되겠지라는 생각을 갖는 것이 대다수일 텐데, 타이머를 0으로 주면 그 즉시 실행이 되지는 않는다. 브라우저에서의 작업은 single thread로 처리되기 때문에, 타이머를 통해 등록된 함수는 당장 실행되지 않는다.
먼저 작업 큐에 추가되고, 브라우저에서 별도의 다른 작업이 실행중이지 않으면 큐에 등록된 함수가 실행되게 된다.
+ 참고 : How JavaScript Timers Work
이때 타이머 호출을 위해 지정한 시간은 과연 얼마나 정확한가? 라는 의문이 생기게 된다. 타이머 호출의 정확성에 대해 좋은 글이 있어 간략히 아래와 같이 정리해 봤다. (정확히는 크롬 브라우저에서의 타이머 처리에 관한 글이다.)
윈도우 어플리케이션들은 아키텍처상 Event Loops의 상위에 일반적으로 위치해, 어떤 작업이 나중에 실행되도록 스케줄링하기 위해 큐에 넣고 작업이 실행되는 시점에 프로세스가 깨어날 수 있도록 하게 된다.
이와 같은 처리를 위해 윈도우에선 기본적으로 WinAPI의 WaitForMultipleObjects()를 사용해 처리한다. 이 API는 UI 이벤트, 파일 이벤트 그리고 커스텀 이벤트를 위해 사용되는데, 이러한 이벤트들에 대해서 윈도우는 실행 주기의 기본값으로 15ms를 갖는다. 즉, 1ms로 timeout을 설정 하더라도 15ms의 주기를 갖기 때문에 15ms 아래로 설정하는 것은 의미가 없게 됨을 의미한다.
이러한 기본값을 변경하기 위해서 윈도우의 멀티미디어 타이머 API에 속해 있는 timeBeginPeriod()를 사용할 수 있는데, 이 함수는 클럭 주파수를 변경할 수 있게 한다. 하지만 이것도 최소 설정할 수 있는 주기의 값은 1ms 이다.
그러나 timeBeginPeriod()를 사용하는 것에는 아래와 같이 2가지의 위험성이 존재한다.
1) 자신의 프로세스만이 아닌 시스템 전체에 영향을 미치게 되는점
2) 시스템이 절약모드 상태 전환에 영향을 미칠 수도 있는점
그러나 Windows Media Player, and even QuickTime에서 이미 사용되고 있고, 이 API의 사용으로 인한 위험성이 크게 걱정할 수준이 아닌것으로 판단되어 크롬에서 빠른 주기의 타이머에는 timeBeginPeriod()를 사용하도록 처리한다.
(Windows Power APIs를 통해 배터리를 사용하는 노트북에서는 빠른 timer를 사용하지 않도록 스위칭하도록 설정)
WebKit 코드에서는 자체적으로 10ms 보다 빠른 처리는 실행되지 않도록 처리하고 있으며, 그 외 브라우저 들도 대체로 이러한 제한을 두고 있는데, 이렇게 설정한 이유는 아래와 같다.
1) 관례적
2) 제대로 작성되지 않은 웹 사이트의 경우 timer를 과도하게 사용 또는 잘못 사용하게 되면 CPU의 사용률과 브라우저에 영향을 미침 (이런 현상은 결국 브라우저의 잘못이라고 사용자들은 생각하게 될수 있기 때문에 일부러 제한을 설정)
3) 과도한 타이머의 사용은 싱글 프로세스 브라우저 구조를 갖는 브라우저에서는 브라우저의 다운을 가져올 수 있음
각 브라우저에 따라 최소로 설정될 수 있는 타이머의 주기는 아래와 같다.
IE8 및 그 이하 : 15.625ms
IE9+, Chrome : 4ms
FF, Safari : ~10ms
최근 덧글