갑자기 왜 인신공격하노...

트라이 구문안에 들어간다고 느려지는건 아니지않음? 에러터졌을때 에러 throw하는게 느리다는거아닌가

그리고 에러가 수시로터지는 시스템이면 그게 문제인거지 try catch가 병목일수있다는게 이해가안됨

잘못알고있는 부분이 있다면 지적좀 ㅇㅅㅇ

니가 그렇게 쳐 말하면 트라이 캐치 모델이 느린건지 캐치가 느린건지 throw가 느린건지 어떻게 알음?

트라이 캐치 모델은 존나 느린게 맞음

트라이 구문 안에 들어가면 느려진다고 표현을 하던가 씨발 당연히 try~catch는 병목이지 stack unwind code가 생성되서 최적화가 덜 되는데

트라이캐치안에 넣기만해도 느려짐?

난 트라이캐치안에 넣는건 느려지는거랑 별 상관없다고 생각했는데 아닌갑네

실제로 stack unwind code를 뺐을때 내 경험상 국소적으로는 최대 14%의 성능 이득 봤다.

니가 트라이 캐치 모델을 사용하는것과 트라이 캐치 안에 코드를 집어넣는것의 차이를 모르니까 빡대가리라고 한거임 빡대가리야 또 또 트라이 캐치 안에 넣기만 해도 느려지냐 이지랄하네

모델을 사용하게 되면 stack unwind를 위한 코드가 nothrow를 제외한 모든 코드에 포함되게 되고 그것 자체만으로 당연히 영향을 미침

니가 try~catch 구문 안에 코드를 넣는거랑 안 넣는거랑은 전 혀 상관없다고 븅신아

존나 1차원적인 생각만 하니까 이런 질문을 하지 ㅋㅋ 존나 웃기네 try~catch 안에 코드를 넣으면 느려짐? 이라니 ㅋㅋㅋ

이새끼는 뭐냐

씨플플은 트라이 캐치가 포함된 코드가 실행이 안 되거나 정말 드물게 실행되도 프로그램 전체 수행 성능에 큰 영향을 미침? 씨플플 잘 몰라서 물음

ㄴㄴ 다른것과 마찬가지로 많이 실행되는 코드가 stack unwind code때문에 최적화에 실패하거나 추가적인 코드 생성때문에 branch scope가 바뀌어서 전체적인 BB flow자체가 바뀌면 크게 성능이 바뀜.

forceinline 하나 잘못 써서 전체 inline 흐름이 바뀌는거랑 비슷한 흐름임. 원래 인라인되려던 함수가 너무 커져서 인라인 못하고. 그래서 그걸 인라인하려던 함수가 너무 작아져서 그 전 함수가 다음 함수를 인라인하고. 이런식으로 나비효과가 심함. 이렇게 되면 전체 인라인 cost랑 scope가 완전히 바뀜. 마찬가지로 이것도 code-size와 side-effect에 관련된것이라서 운 나쁘면 성능이 매우 떨어짐. 원인 찾기도 힘듬.

trade-off없이 동일한 behavior에서 1% 성능 차이만 나도 엄청나게 큰 차이인데 당연히 심각한 병목임.

그렇군여, 글쓴이가 묻고 싶은 게 이거였는데 질문이 좀 이상했던 거 같음.

모든건 컴파일러랑 아키텍처가 블랙박스라서 생기는 문제임. 그래서 컴파일러 개발자들이 code bloat를 경계하는것

하지만 빡대가리랑은 상관없다고생각함, 당연히 모를수도있는거 아니겠노...?

어쨌든 단순 사용만으로도 전체적인 병목을 불러올수있나보군, 그럼 별로인게맞네

또 궁금한게 컴파일러가 블랙박스인데 그렇다고 아예 예외처리를 안할수는없지않음?

아 C++안써요

씨플플도 아닌데 왤케 민감하시죠

민감해져버렷~

그래서 물어봤는데 첫댓이 빡대가리라고그러네

읭 무슨뜻임? 예외처리가 흐름제어수단이라는게?

Promise.catch같은게 좋은디자인이라 보는거?

여튼 두개 주제를 한꺼번에 말한거같긴한데 일단 첫 얘기부터 다시 설명해주셈

가끔 예외를 진짜 예외 상황에 던지는게 아니라 그냥 분기에서 쉽게 빠져 나오려고 던지는 관행이 있거든. 위에 이야기처럼 언어 구현에 따라 그건 일상적으로 사용할 경우엔 오버헤드가 무시할 수 없기 때문에, 예외 처리에 대한 성능 차원의 비판이 유효할 수 있는 사례라고 본다.

분기에서 쉽게빠져나오려고 던진다...? 그냥 리턴으로 나오면 안되는거냐...그런 언어를 주력으로 삼아본게아니라 잘 모르겠네

나는 제어를 외부에맡기는 경우에만 트라이캐치를 씀(네트워크 콜 같은것)

분기에서 빠져나오려고 던지는거면 님 말대로 걍 오용아님?

반면에, 예외 상황에서 예외를 던지는 건 위에 다른 사람이 언급한 대로 그게 막 초당 100번 씩 발생하면 코딩 자체를 잘못한 거니까 try-catch 자체를 비판할 거리는 못되고. 오히려 프로그래밍 모델 차원에서 예컨대 함수형에서 예외 분기를 다른 값으로 변환한다던지, 컴포지션을 한다던지 그런 식으로 처리하는게 더 깔끔한 경우가 있으니 그런 면에서 장단점을 따지는 게 더 유효한 이야기 같다.

ㅇㅇ 오용 맞음, 근데 가끔 보는 관행이기도 하고. 내가 이해하기로 try-catch 자체가 성능이 느리다는 비판은 그런 오용에 대한 지적으로 더 적합하단 거지, try-catch의 존재 자체가 아니라.

그럼 첫댓은 그저 인신공격일 뿐이었군...

그러면 결국 트라이캐치의 성능은 왈가왈부할게 못되네, 다만 표현법이 마음에안들수는 있어도

난 그렇게 생각하는데, 이건 내 생각일 뿐이니 다른 주장이 있을 수도 있겠지.

파이슨도 철학에서나 그런 소리 하는데 가능하면 안 씁니다..

첫댓은 뭔가 몰라서 평가를 못하겠고 이횽댓글이 나랑 생각하는게 똑같음. 간혹 스택뎁스가 깊어지는거 때문에 트라이캐치를 분기용으로 쓰는 괴랄한 코드를 회사 서비스에서 본적 있는데 다 뜯어고침 - dc App

일상적으로 트라이캐치를 도배한다는거...? 뭔가 이상한데

stl만봐도 에러핸들링 예외로 하자나

위에 말했듯이 흐름제어로 쓰는건 오용인부분아닌가...C++의 문화는 좀 다르나?

에러핸들링 예외로하는건 맞는데 에러가 일상적으로 발생하는건 아니다 이거지, 에러가 발생할때만 느린거잖어

그리고 프로그램에서 에러가 발생할때는 굉장히 일부잖아, 그게 유저입장에서 병목을 느끼게하는가? 난 아니라고보거든

느리다는것도 상대적인거고...

여튼 수치적으로 요약하자면 0.01%정도로 발생하는 에러에대해 조금느리다고 하는건 굳이 상관없지않는가? 이게 내 궁금증이었음

병목도 비중이 큰 부분을 해결하는거지 트라이캐치가 병목일리가없잖아

하나씩만 달아 ㅅㅂ

여기가 디코 채팅방인줄아누

ㅇㅅㅇ;;

throw 되는 상황이 애초에 일어나지 않도록 하는 문화가 구린 성능때문이란거임 배열접근마다 트라이 캐치해서 분기하면 욕먹지만 Option같은 타입이 제대로 들어있는 언어들은 일상적으로 하는거임

오잉? 뭔가 이상한데...배열접근마다 트라이캐치를 하는건 미친놈아닌가

원래 외부에 제어를 맡기는경우에만 트라이캐치를 쓰는거아님?

그러니까 그 문법이랑 성능때문에 그런식으로밖에 못쓰인다고

아 그러니까 에러처리 존나도배하고싶은데 트라이캐치는 그럴때 쓸수없으니 줫같다...그런건가

그래서 땜빵으로 null같은 ㅂㅅ같은거 쓰잖아

std::vector::at이 std::out_of_range를 던짐

으음...그 부분이 이해가 안가는건데 이건 C++로 프러덕션 뛰어보는게아니면 모를라나

그치만 아무런 오류 핸들링도 하지 않는것보다는 낫다고 봄

인풋을 완벽하게 통제하는게 맞지않나...난 그렇게 생각해와서

제어가 외부에맡겨져서 통제할수없는 상황인 I/O나 네트워크통신에는 당연히 예외처리해주고

그건 맞음
암튼 트라이 캐치로 성능 병목이 생긴다면 그건 프로그래머 잘못임

그렇구만

딥러닝은 모르겠다, 워낙 한번돌리는데 오래걸리고 예측도 잘 안되지않음?

데이터 전처리할때 주로 - dc App

그리고 주피터로 한번쓰고 말 스크립트 쓸 땐 걍 암튼 되면 좋다 이런 느낌이라 - dc App

난 파이썬 한 지 얼마 안됐는데, EAFP는 안티패턴이라고 생각함. 성능은 그렇다 치고, 코드 너저분해지고 메서드 이어 쓰거나 하면 각 단계에서 정확하게 무슨 예외가 발생하는지 미리 알아야 하고, 또 진짜 코딩 문제로 예외가 발생했는데 구분이 안갈 수도 있고...