SI회사에서 일하면서 들어본, 기억에 남는 3대 헛소리 적어봅니다.
1. IF문을 최대한 적게 써라. IF문이 많아서 속도가 느리다.
- 코드 짜는데 IF문을 생각해서 적게 쓰라니 이게 말인가요 방구인가요.
성능은 알고리즘의 시간 복잡도에 비례하는거 아니었나요.
integer 수치 비교하는 IF문 3개 라인 쓰고 들은 말입니다.
그리고 해당 코드는 switch 문으로 바뀌었습니다.
물론 테스트 해보니 성능은 그대로였죠. 아시잖아요 SI는 이런곳이에요. ^.-
2. Java 와 C 중에 실행속도가 더 빠른것은? - Java 라네요???
- 상황따라 다르겠지만 일반적으로 C가 메모리 직접 접근이 가능하기 때문에 더 빠르고,
Java는 jvm 상에서 실행되니 일반적으로 더 느리다고 대답했더니 폭소를...
대답도 안해주시고 그저 비웃기만 하고 답을 안주시더군요.
경력 13년 차인 지금도, 저는 왜 그렇게 웃었는지 이해가 안됩니다.
3. 파일명은 생성 순서대로 숫자4자리로 넘버링해서 관리하되, 주석은 적지 않는다.
- C로 작성된 각 소스 파일은 숫자 4자리.c 와 숫자 4자리.h 로 관리됩니다.
숫자의 의미와 체계는 선배들에게 구전으로 내려옵니다. 비전이라네요?
선배들이 뭔가 프린트해서 대물림하는 설계도가 있는데, 보기만 해도 복잡합니다.
소스코드는 무려 웹하드!! 에 있습니다.
서버에서 돌아가는 아주 멋진 증권 거래용 멀티스레드 프로그램이었는데,
이전에 어떤 멋진 전설의 개발자 분이 무려 3! 중! 포! 인! 터! 를 활용하여 코딩을 해놓으셨습니다!
Semaphore나 Context 구분이나 그 어떤 것도 없고! 그냥 3중포인터만 있는 전설의 프로그램이랍니다.
무언가 코드를 한줄이라도 건드리는 순간, 동작은 말 그대로 혼파망이 됩니다.
저는 그냥 Print문 하나 찍었을 뿐인데, 말도 안되는 거래가 무작위로 일어납니다?
역시 저는 천재가 아니라서, 코드를 짜면 안되나 봅니다.
지금은 멀쩡한? 곳에서 즐겁게 개발하고 있습니다만,
저랬던 시절도 있었습니다.
잠이 안와서 뻘글 적었는데, 읽어주셔서 감사합니다.
좋은 하루 마무리 되시길!
저는 for 문을 좀 줄이라는 말은 많이 들어봤습니다.
이건 맞는 말인것 같습니다. ㅋㅋㅋ
짠밥이죠
그런데 실제로 반복문 같은데서 로그 찍냐 안 찍냐가 속도 차이를 만들긴 해서 할 말은 없긴 합니다.
임베디드는 시스템에 따라 다르겠지만.. 로그 찍는게 속도에 지장을 줄 수 있는 경우가 많습니다 ㄷ ㄷ
다만 저는 서버 좀 쓰더라도, 빠른 현상 파악과 원인 분석을 위해 필요한 로그는 남기도록 권장합니다.
백엔드 할 때는 전혀 신경도 안 쓴 것들이... (속도가 느리면 서버 사양을 올리는게 정답입니다를 외치다가.. 임베디드로 오니..)
네. 그래서 개발 할 땐 prtintf 그냥 막 쓰다가도 양산테스트나 코드 릴리즈 할 땐.. 다 빼고 테스트 하는게 정석이긴 합니다. 그게 들어가야 정상작동 한다면.. 차라리 딜레이를 쓰면서 필요한 타이밍을 계산해서 넣는게 나아요.
그리고 결국 문제는 DB connection을 무한 생성하고 안 닫으신 그 선배분의 코드로 판명되었습니다. 분석 - 수정 - 패치는 제가 했습니다. ㅎㅎ
if / switch 는 꽤 오래된 떡밥인데, 조건 갯수가 많아질수록 switch가 통상 유리한데, 요즘은 컴파일러서 거르긴 합니다만
저게 10년전 이야기면 저 이야기가 틀린건 아니죠. 물론 꼴랑 3개가지고 if / swtich 따졋으면 한대 때려야.
그리고 임베디드 쪽이면 여전히 저거 따져야합니다. 프로세서 성능이 제약적이니까요.
다만 환경은 윈도우였고, 실제 성능 하락 원인은 DB connection을 마구 생성한 다른 코드였습니다. 아마 말씀하신 내용을 선배가 자랑하고 싶으셨던 것 같아요.
1번은 맞는말 아닌가요 ..
그냥 단순히 3개 썼는데도 그런소리 한게 미친거 같지만..
많은 조건에선 switch 가 훨씬 빠르다고 어디서 본거 같아요
1. 네 저도 비슷한 이야기를 들어본 적이 있습니다. 다만 대부분의 코드가 그렇듯이, 성능저하는 IF문 보다는 For문의 과다한 사용이나, 불필요한 DB Access, 디스크 I/O, 무한 loop에서 발생하는 상황이었습니다.
3. 아직두요? 저때는 SVN 시절이긴 합니다만... 그때도 웹하드와 메일에서 소스코드를 관리하시더군요. 그분은 fox를 사랑하셔서 모든 코드를 fox로 짜신 전설이었습니다.
if나 switch 많이 써야하면 펑션포인터로 처리하는게 베스트긴하죠. 손이 많이 가서 그렇죠
원투 스트레이트 맞고 어질 어질
(1번글과 2번글)
3번글에서 떡 실신했습니다 ㄸㄷ
이 댓글은 실신한 이후 정신차리고 쓴 글입니다
https://en.wikipedia.org/wiki/Branch_table
이걸 응용한 사례로 Duff's Device가 있습니다 ( https://en.wikipedia.org/wiki/Duff%27s_device )
2. 무슨 소리인건지..
3. 정하기 나름일듯 은한데 합리적이지 않으면 바꿀수 도 있는것이지요 무조건 따르라니.
1. 임베딩 분야이거나, 게임 코딩이라면 있을수 있는 이야기였군요. 알려주셔서 감사합니다. 저도 보통 if - else 두단계가 아니면 switch 문을 쓰긴 합니다만, 모르고 사용하고 있었네요.
2. 지금의 저도 그분이 무슨말을 하고 싶었던건지 모르겠습니다. 답을 주셨으면 좋았을텐데 말이죠 ㅠ
3. 음.. 지금의 프로그래밍 트렌드를 생각하면 아무리 잘 정해도 안 좋은 구조라고 생각합니다.
좋은 코드는 이해하고 유지보수하기 쉬운 코드이고, 넘버링과 주석없이 천재들만 이해할 수 있는 코드는 조금 심하게 말하면 쓰레기라고 생각합니다. 결국 버려질테니까요. (실제로도 지금은 완전히 버려졌다고 들었습니다.)
2. 그때 그때 다르죠 ㅎㅎ
3. 3중 포인터는 쓰지 말라고 배운는데 말이죠 ㅎㅎ
요
1. 엇 정말요? ㅠㅠ 안되는데... if 문은 사랑입니다.
2. 진리의 케바케입니디만, 저 질문을 저에게 먼저 던지셨고, 제답엔 그냥 웃으셨고, 퇴사할때까지 몇번 더 물어봤는데 답은 안주시더군요.
저때는 정말 Pure C와 Pure Java 시절 질문하신 거라서, 제 답이 큰 틀에서 틀리지 않다고 생각합니다.
3. 음.. 3중 포인터는 전설이고, 정말 대단한 기술이라 꼭 써야 한다고 들었습니다.
물론 제 팀원이 3중 포인터를 쓰겠다고 한다면 불러다가 설득해보고, 그래도 안되면 이직을 고민해보겠습니다.
그나저나 임베디드도 임베디드 나름이라 저는 usb 5gbps daemon 에 pthread 로 비동기 logging 하도록 쓰는데 cortex a72 이상이면 사실 성능 하락 없다 봅니다. ㅎㅎ
사실 저는 GPU를 쓰는 코딩으로 넘어와서, 행복하게 컴퓨터 성능을 믿습니다. 말도 안되게 느리면 그때가서 프로파일러 돌립니다. ㅎㅎㅎ
다만 저때 Java는 Linux에서 돌리는 환경이었고, C 대비 정말 느렸어요.
아마도 if.. else if.. else if.. 이 구조를 말하는 걸로 알고 있습니다.
처음 코딩시에는 많지 않지만, 조건이 계속 추가되면 else if 가 모니터 하나를 꽉 채우고도 주욱 가더라고요
그럼 맨 앞의 if를 물고 계속 이어지는 구조라 메모리도 그만큼 더 쓰면서 해당 모듈이 중첩되서 돌아가면 느려지는 건 맞을거에요
1 depth 에서 condition 비교하도록 if를 짜게 되면 모든 if문을 지나가야해서 비효율적이고,
switch가 조건 찾아서 다이렉트로 가서 처리하니까 switch가 가장 빠르죠..
특히 서버 등 성능 좋은 거 말고 폰 같은 성능 낮은(이마저도 요샌 높아졌습니다만, 예전에는 꽤 낮았습니다...)거에선 티가 날수 있습니다.
단 몇개 안되면 그넘이나 저넘이나 다 똑같죠 ㅎㅎㅎㅎ
2. 대답 없이 비웃는 분들 주요 특징이 잘 모른다입니다.
어서 듣긴 들었고 본인도 그렇다고 알고 기억해놓은건데
후임자에게 알려줬다 왜 그러냐고 이유를 물으면 디테일하게는 모르거든요..까먹었거나..
그럼 실실 쪼개는 거나 화내거나를 시전하시죠.. 안 그럼 꼬치꼬치 물어볼테니까요 ㅋㅋ
3. 갓 입사해서 할 때 변수랑 이런 저런 것들을 암호처럼 해서 코딩했는데
윗분(그 당시 저한테는 꽤 높으신...)이 어떻게 제 코드를 보게 되서
머라머라 한 소리를 10분 정도 하셨죠...
네 누가봐도 모르게 의도적으로 코딩한 거 맞습니다...ㅋㅋ
혼나고 나서는 제대로 코딩은 했습니다만..
그때는 왜 그랬나 몰라요..^^;
제가 아는 다른분은 제대로 코딩한다고 로그상 프린트 우선 정리했는데 구동이 안되서 다 엎고 기존대로 가신분도 있었는데...개인이 다 엎을거 아니면 기존 주먹구구로 돌아가도록 한 구조는 수정이 쉽지는 않더라고요
2. 그러게요. 뭐라도 불완전한 답이라도 주셨으면 차라리 좋았을거에요. 그래서인지 저는 후배가 뭔가 물어보면 아는 선에서 최대한 대답을 주되, 좀 더 찾아보라고 이야기 합니다.
3. 이때는 뭔가 남들이 손대기 어려운 코드를 짜면 멋있게 보이는 풍조?가 있었던 것 같습니다. 개발 방법론 같은 것도 없고, 뭔가 선배의 코드를 신성시 하는 그런거죠. 지금은 어떤 코드를 짜도 3년 이상 가기 어렵다 라는 마인드로 짜고 있습니다. 항상 새로운 코드와 기술이 나오더라구요. ㅠㅠ
저는 파일 하나가 if문과 함수만으로 떡칠된 파일을 발견하고 제 스타일대로 구조잡고 쪼갰더니 파일 1개가 400개로 쪼개지는 경험을 해본적이 있네요.
몇 라인이셨길래 400개로 ㄷㄷㄷ 그 정도면 거대 프로젝트네요.
- switch 로 최적화 될 수 있는 경우는 한정적입니다. 매우 연속적인 값으로 case 문이 구성되거나 그래야 합니다. 아니면 switch 도 그저 if 문의 반복과 똑같습니다.
- 어떤 작업이든 제대로 구현했을 때 c가 Java 보다 느릴 가능성은 거의 없습니다. 포인터를 안써도 이는 변함이 없습니다. 다만 대충 구현하면 java가 그나마 실수 가능성이 조금이라도 낮아서 java가 빠를 수도 있겠죠. 아마 웃으신 그분은 이걸 의미하지는 않으셨겠지요
- c 계열 언어에서 if, else if 문의 반복에 한계가 있습니다. 컴파일러에 따라 다를 수 있습니다만, 살다 보니 이 한계를 볼 기회가 있었고 매우 놀랐...었습니다. 이런 경우 switch가 강제될 수도 있겠습니다만... 비교하는 값이 숫자가 아니고 문자열이라면 어떻게 해야 할까요? ㅋㅋ
오늘 이상하게 일이 안돼서 줄줄이 적어 봤습니다.
- https://en.wikipedia.org/wiki/Branch_table 를 어느분이 알려주셨습니다! 제가 짠 코드에 적용되는 사항은 아니라고 생각됩니다만, 역시 코딩의 세계는 깊고 넓네요.
- 저도 그렇게 생각합니다. 동작이 명확하게 정의되어 있고, garbage collector를 사용하지 않고 직접 제어한다면, 일반적으로 C가 항상 빠른게 맞다고 생각합니다.
- 사실 if vs switch 보다도 문제에 맞는 알고리즘을 적절하게 썼느냐 - 문자열 탐색이라면 kmp 또는 moore 알고리즘- 를 고민하는게 더 좋다고 생각합니다. 예전에야 쥐어 짜내는 게 중요했지만, 지금은 하드웨어를 어떻게 잘 활용하느냐의 시대가 되지 않았나 하는 생각이 드네요.
저도 밤에 잠이 안와서 이러고 있네요. 자러 가야겠습니다!
좋은 밤 되세요~!
Java 는 바이트코드로 바꾸면서 최적화 과정이 추가가 되긴하지만... 같은 프로그램인데 C 보다 빠르게 만들어질 일이 있을지....
마지막 3번째는 진짜 계약연장의 의지를 담은 코드인가요.... ㄷㄷㄷ
두번째 폭소를 한건 할말없고 창피해서 그렇게 라도 안하면 들킬까봐 인거고...
마지막은 소스를 4자리숫자에 프린터물로 전수해주다니...어렵게 만들어서 나만아는 코드를 나만 설명해줄수 있게하겠다.. 내개똥같은 문서를 성전처럼 받들어라..뭐 이런 컨셉이군요.. 팀장이 코드검수 안하나요?
브랜치 명령어에 의하여 control hazard 케이스는 컴퓨터 아키텍쳐의 근본적 구조적 문제입니다.
branch prediction 혹은 predication 같은 기법으로 브랜치 명령어에 대한 penalty 를 줄일 수 있지만 100% 해결 할 수 없거든요.
다만 프로세서의 파이프 라인 구조를 고민 하고 몇 clock 사이클 손해 보는 것을 고려하면서 프로그램을 짠다는 것은 말이 안되는 소리죠. Assembly coding 하는 것도 아니구요.
이말 했던분 개발 못하는 pm 이셨습니다..
if도 현대 cpu는 미리 계산해놓고 분기에 따라 계산 결과를 버리기에
(그리고 미리 캐쉬도 채워넣고 버리고 하기에)
그걸 고려해야 할 정도로 쥐어짜는 프로젝트들이 좀 있기는 해요.
CPU 및 주변 기기들의 구조에 대하여 빠삭하고 어셈 레벨로 코딩이 가능한 사람들이 필요한 프로젝트들 말이죠. ;;;
문제는, 그걸 알고 경험해서 말하는 사람들은 때와 장소, 그리고 프로젝트를 가려서 말한다는 거죠.
가장 기본적인 if, for, switch 가지고 트집 잡는 사람들은 뭐하는 사람들이죠?
ㅍㅎ
요즘은 컴파일러 최적화가 잘되어 있어서, if로 짜든 switch로 짜든 어셈블리는 동일하게 나옵니다.
2. 컴퓨터공학개론도 안들었거나 두 언어를 모두 다뤄본 경험이 없거나 겠네요. 대학교 1, 2학년 때 다 하는 것인데요.
C로 코딩하다 JAVA 시작하는 순간 너무너무 느려서 깜짝 놀랐던 기억이 있네요. 이건 싸울게 아니라 같은 로직을 두 개로 짜서 돌려보면 바로 검증이 가능하죠
3. 삼중포인터는 잘 쓰면 엄청 효율적인 코딩이 가능합니다 (문자열을 다루는 경우는 그냥 이중 배열 쓰는 것과 크게 다르지 않기 때문에요) 근데 주석없이 짜는건 협업에서는 자살행위죠. 자기도 기억 못할텐데요.
2. 2번을 이야기하는 사람들이 가끔 있긴 합니다. 저도 웹 개발쪽으로 넘어가면서 어떻게 C 로 짠 코드가 자바로 짠 코드보다 빠를 수 있냐는 말을 하는 사람들이 종종 보긴 하거든요. 제가 Spark 로 한창 고생하고 있었을때, 같이 개발하던 분도 그런 이야기를 했는데, 병렬화나 분산처리쪽으로 넘어가면서 자바가 훨씬 빠르다는 식으로... 그 분은 Embedded 개발이나 어셈블리 또는 진짜 극단적인 최적화 개발은 해본적이 없는 분이라 그럴 수도 있다는 생각은 했습니다. 같은 연산을 그냥 C++ 로 만들어서 보여드리고 나서부터는 납득하시고, 포인터때문에 C++ 이 두려웠다는 이야기를 하셔서 그런갑다 했습니다.
3. 삼중포인터는 쓸일이 많이 없어보여도 은근히 쓰면 좋은 부분이 있습니다. 주석이 없을라면 적어도 변수 명이나 로직 흐름이라도 매끄러울 필요가 있는데, 아무도 안건드린다면 과연 그럴까 싶긴 합니다.
2번은 말도 안되는 개솔.. 스크립트언어는 예외처리 떡칠 되어 있습니다. 아마 캐시의 영향 같네요.
3번은 왜 그랬는지 짐작만 합니다. 나쁜 것이 아니군요.단지 올드할 뿐이죠. bind소스가 더 복잡할 겁니다.
지금도 학구열 높은 후임들에게 if가 빠르냐 switch가 좋쟈 같은 질문이 들어오면 해당 구문 호출이 초당 만단위 이하라고 확신이 들면 시끄럽고 읽기 쉬운 코드로 만들어라고 합니다.
순환문은 4중 이상 순환이 들어갈 때만 한번 더 정말 필요한지 고민해 보라 하고, 재귀호출 쓰면 걱정스런 눈빛으로 보긴 합니다만 뭐라하지는 않습니다.
물론, if문 한번 줄이는건 습관화 되어 있습니다만, 요즘에는 속도보다 가독성이 우선이다는것을 정답으로 해 놨습니다.
2. 굳이 java가 더 빠른 케이스를 꼽으라면,
언어별로 일부 연산은 C보다 더 빠른 속도를 보이기도 합니다.
또, 기본 제공하는 라이브러리가 더 풍부 해서, C에서 제공하지 않는 연산을 아둥바둥 짜봐야 Java에서 제공된 기본 라이브러리 속도를 따라가기 힘든 케이스가 있긴 합니다.
후임들에게 지금 사용하고 있는 언어가 그렇게 느리지 않다라는 인식을 시켜주기 위해서 하는 말입니다만, C보다 Java가 빠르다는... 그냥 웃지요.
3. 90년대 유행하던 업계 농담이 있었죠. 주석 없는 코드, 알수없는 네이밍이 네 정년을 보장해주는 방법이라고. 그 때도 당연히 자조적인 농이었는데... 스트로스튜룹인터뷰가 새삼 생각나네요... ㅎ
실제 그런 코드를 본적이 있습니다. 암호같은 네이밍에, 코딩타임 추적도 잘 안해주던 시절에, 함순지, 변순지, 포인터 타입이 뭔지도 한참 추적해야 하는데다, 전처리기에서 복사해 쓰는 define 코드를 사용하는 매직 코드가 가득했죠.
꼬꼬마 시절에는 그런 코드를 보면서 '아, 내가 이렇게 부족하구나' 하고 생각 했는데 지금 돌이켜 보면 바보같은 생각이었습니다. 비웃어야 했죠.
설계하고 로직 만드는게 프로그래머인데, 코딩에서 희열을 느끼면 안되죠. :)
사실 매직코드 짜는걸 좋아하긴 합니다만 하다가 뭔 코든지 알아볼수 없다라고 후임이 말하면 (후임에게 걸리면...) '신기하지 않냐? 히히. ㅠㅠ' 미안' 합니다. 1에서 적었듯, 성능보다 가독성이 우선이거든요.
난해하게 짜고 다른사람이 못건들게 하며 결국 나에게 입금하게 만든다.
늦게 시작해서 그 흔한 SI 1인 파견만 나가보니
그지?같아도 선배같은 분이 있었으면 좋겠다 싶었네요 ㅜ
예를 들면 if(한국인) ... else if(미국인) ... else if(일본인) ... else if(중국인) ... 이런식으로요.. 그래서 제가 이런 코드는 좋지 않다. switch 문으로 고쳐라 했더니, 이번에는 if문을 써야할 경우에도 switch문을 써서 바꿔놓았더라구요.
switch case(성공)... case(실패) 이렇게요.. 문제는 이 코드를 누군가가 카피해서 쓰다가 중간에 break를 빼먹어서 엉뚱하게 동작하더란 말이죠. 억지로 스위치문을 쓰려고 하니 코드 가독성이 안좋아서 가져다 쓰는 사람도 의미를 잘 모르고 대충 부분적으로 복사해다 넣었더라구요. 이 버그를 찾는데 정말 고생했었습니다.
요즘 시대에 알고리즘에 대한 이야기가 아닌이상, 무슨 구문이 좀 더 빠르니, 어떤 언어가 더 빠르니, 메모리를 덜 잡아먹느니 하는건 의미가 없다고 봅니다. himem 치고 게임하던 도스 시절도 아니고 말이죠.
저는 항상 코드를 이해하기 좋게 쓰라고 합니다. 본인 취향이 뭐든 상관없는데, 불필요하게 어렵게 코드를 작성하지 말라고 합니다. 직업 코딩에서는 이게 가장 중요하다고 생각해요.