최적화 관련

hotspot - 자주 반복돼서 수행되는 구간

jit 컴파일 오버헤드. hotspot이 많을때 유리하다. 컴포넌트 기반 개발 방식은 코드를 재활용하기 좋다. jit컴파일이 코드를 최적화하는 오버헤드가 있더라도, 기존 코드를 재활용하여 개발하면, 성능상 이점을 가져올수있다.

jit컴파일이 코드를 최적화할때 오버헤드가 발생한다. 보다 효율적인 로직으로 코드를 실행하기위해서. 그런데 js는 페이지 레이아웃을 건드리거나, 사용자 입력에 반응하는 방식의 프로그램이 많은데, 한두번만 수행되는 코드가 많으면, 비효율적이다. 왜냐면 위에서 언급했듯이, 코드를 실행하기전에 컴파일러가 코드를 최적화하는데 드는 오버헤드가 있으므로. 그런데 컴포넌트 기반 개발을 하면서 코드가 재활용되는 경우가 많으므로. 한번이상 활용되는 함수같은것은 따로 빼서 관리하는것이, 최적화과정을 한번만 거치기때문에 유리하다. 깨끗한코드와 협업을 위해서도 좋다.

adaptive jitc 는 타입프로파일링을 수행하므로, 변수의 타입이 변하지않는다면 높은 성능을 얻을수있다.

js는 타입이 없다. 하지만 엔진 내부적으로는 타입이 존재한다. profiler는 사용되는 변수들의 타입이나 값을 profile해 두었다가 optimizing jit를 적용할때 이들 정보를 이용하여 예전 jitc에서 생성했던 예외처리 루틴들을 대폭 생략한 효율적인 코드를 생성한다. 이런 코드를 생성할때, 예외적으로 loop를 n번 수행하는동안 x라는 변수가 계속 int였다가, 그다음 iteration에서 갑자기 string으로 바뀌어버리는 경우, optimizing jitc로 생성된 그 효율적이었던 코드는 유효하지않게된다. 그래서 다시 예전 baseline-jitc로 생성한 코드로 수행하게된다. 예외상황이 발생하면 overhead가 커진다.

profiling을 수행하는동안 특정변수의 타입이 변하지않으면, 그 이후에도 그 변수는 타입이 변하지않을 가능성이 높다 라는 가정하에 최적화를 하기때문에, js에서 변수의 타입을 바꾸는것은 성능상 매우매우 좋지않다. 따라서 변수의 타입을 바꾸지말아야한다. 변수의 타입이야기가 나왔는데, ==는 변수의 타입이 다르면 변환후 비교하기때문에 명시적으로 변환하여 ===로 비교하는게 낫다

웹브라우저 동작과정

1.서비스 이동 단계(Prompt for unload) 사용자가 웹서비스를 이용하다 다른 주소로 이동할때 브라우저가 제일 먼저 실행하는단계

1. 리다이렉트 단계 사용자가 요청한 url에서 다른 url로 보내는 단계

2. 앱 캐시 확인 단계 브라우저의 캐시에 데이터가 있는지 확인

3. 네트워크 통신 단계 (dns, tcp, request, reponse) 브라우저가 네트워크와 통신해서 웹페이지와 구성 요소를 다운로드

4. 브라우저 처리 단계(processing, onload) 다운로드한 웹페이지와 구성요소를 웹페이지를 화면에 렌더링하는 단계

웹사이트 최적화

url끝에 /를 붙인다. 안붙이면 리다이렉트함.

웹페이지에서 동시에 많은 변수가 생성되고 처리되는 동안 브라우저에서 허용한 임계치를 넘었을때 GC가 동작하고, GC가 동작하면 스크립트 실행이 중단된다. GC가 완료되기 전까지 스크립트가 동작하지 못해 페이지가 느려진다.

DOM의 생성과 삭제가 빈번한 페이지, 한페이지에 다수 ajax 통신이 필요한 페이지, 이벤트 바인딩 수가 많은 페이지, 사용자 체류시간이 긴 페이지를 개발할때는 필요없는 변수가 오브젝트 삭제, 이벤트 해제등을 활용하여 메모리 관리를 해야한다.

리다이렉트할때 메타태그로하면 좋지않다. 메타태그에 있는 페이지를 거쳐야 리다이렉트된다는점이다. 그리고 메타태그가 있는 페이지에 이미지, 스타일시트, 스크립트등의 링크가 존재한다면, 해당 리소스를 다운로드한다. 불필요한 파일들을 다운받는건 손해이다. Fiddler로 301, 302 코드가 발생하는 요소들을 찾아 의도치않게 리다이렉트되는 부분을 제거하자.

네트워크를 통해 무언가 가져오는 작업은 느리고, 비용도 많이 든다. 크기가 큰 응답은 클라이언트/서버 사이에 많은 왕복을 필요로한다. 그래서 http캐싱은 중요하다.