감사합니다.

void main()

{

int a;

int b;

int c;

a=1;

b=1;

c=a+b;

...

}

위와 같은 코드가 있을때,

컴파일 속도에 영향을 미치는 요인은 어떤것들이 있을까요?

눈에는 보이지 않지만, 문장의 끝에는 \r\n 2개의 문자가 들어 있습니다.

그리고 앞에는 Tab문자가 들어 있습니다.

컴파일러는 1문자당 1바퀴 루프를 돌게 되는게 일반적입니다.

루프문 1바퀴를 돌려면, 여러가지 조건이 있고, 이 조건을 포함해서 돌게되면,

최소 몇 클럭은 필요합니다.

1문자 때문에 최소 몇클럭씩 낭비가 되는것입니다.

위 코드를 아래와 같이 바꾼다면,

void main()

{

int a,b,c;

a=1;

b=1;

c=a+b;

...

}

개행문자(\r\n) 4문자와 "int " 2개, Tab 2개가 없어졌으니,

총 4+4+4+2=14문자가 사라졌습니다.

컴파일러는 14문자만큼의 루프를 덜 돌아도 되며, CPU클럭으로 따지면, 

1문자당 3클럭으로 계산해도, 최소 42클럭이상 빨라진것입니다.

또한 소스코드를 로딩할때도 이미 소모된 클럭이 있으므로, +@로 처리시간이 단축됩니다.

여기서 조금 더 나아가면,

- 변수명을 짧게

- 불필요한 공백을 사용안함

하면 +@의 효과를 얻을 수 있습니다.

물론, 코드의 가독성은 떨어집니다.

적당히 줄이세요.

"그거 줄여봐야 얼마나 되겠어?"

"요즘 CPU가 얼마나 빠른데?"

하시겠지만, 이런 수천 라인의 소스파일, 수천개를, 컴파일하게되면, 분명히 시간차이가 발생합니다.

또한, 파일에 저장하기위한 공간도 줄어듦니다.

무리하게 할 필요는 없고, 지금부터라도, 불필요한 공백은 자제합시다.

요약 : 불필요한 중복된 문자(동일한 변수형 반복), 불필요한 개행문자, 긴 변수명은 자제하자.

우스개 소리로, 예전에 마이크로 소프트사와 유닉스 진영에서 개행문자(\r\n)에 대한 논의(?)가 있었습니다.

유닉스진영에서는 개행문자가 \n 1바이트입니다만, 마이크로 소프으 윈도우에서는 \r\n 2바이트입니다.

컴퓨터에 있는 파일의 적지않은 용량의 파일이 택스트 문서이고,

해당 문서에서 개행문자때문에 소모되는 공간도 무시할 수 없다는 것입니다.

지구상의 모든 컴퓨터의 하드디스크에서 무시할 수 없는 공간이 낭비된다는 것입니다.

하드디스크 공간이 비약적으로 늘어나서, 그 피해가 너무 작을뿐, 낭비되는것은 맞습니다.

마이크로 소프트사에서는 이 문제 때문에, \r\n을 \n 으로 바꾸려는 시도를 하기도 했었습니다만, 엑셀, 비쥬얼베이직 같은 프로그램에서 문제가 발생하여, 중단한것으로 알고 있습니다.

유니코드문자를 사용하는 요즘에는 2배로 낭비되고 있습니다. ㅎㅎ