능력이 다른 개개인 갈궈서 최적하 해봐야 중구난방일테고
대충 설계부터 철처한 객체지향, 작은 단위의 모듈 위주로 설계한 후에
프로그램 시범으로 돌리면 리소스 많이 잡아먹는 모듈이 나오겠지.
파레토 법칙에 따라 상위 20%의 모듈이 80%의 리소스 차지
상위 4%의 모듈이 64%의 리소스 차지 할 터이니
그 부분만 중점으로 최적화 하거나 재설계 하는 식으로
최적화 완료!
하는건... 존나 땔깜스런 상상이려나
아니면 땔깜도 웃고갈 병신짓거리일려나?
사실 이런식으로 할거면 설계때부터 리소스 많이 잡아먹는 부분 예상한 다음에 그 부분에 집중 하는게 더 효율적이긴 하겠지만 존나 우수한 설계자가 필요할거 같아
대충 설계부터 철처한 객체지향, 작은 단위의 모듈 위주로 설계한 후에
프로그램 시범으로 돌리면 리소스 많이 잡아먹는 모듈이 나오겠지.
파레토 법칙에 따라 상위 20%의 모듈이 80%의 리소스 차지
상위 4%의 모듈이 64%의 리소스 차지 할 터이니
그 부분만 중점으로 최적화 하거나 재설계 하는 식으로
최적화 완료!
하는건... 존나 땔깜스런 상상이려나
아니면 땔깜도 웃고갈 병신짓거리일려나?
사실 이런식으로 할거면 설계때부터 리소스 많이 잡아먹는 부분 예상한 다음에 그 부분에 집중 하는게 더 효율적이긴 하겠지만 존나 우수한 설계자가 필요할거 같아
나중에는 꿈에 나오는 물건들 위에 클래스명이랑 필드가 막 떠오르고 그런다더라(실제로 들은 말)
단체작업에선 최적화보다 무결성이 중요하고, 꼭 필요한 인터페이스들에 맞춰 작성되면 사실 그닥 퍼포먼스가 떨어질 설계가 나오지 않아요.
보통 성능에 문제가 있다고 판단된 블럭에서만 퍼포먼스 프로파일을 측정해보고 문제요소를 제거하는식이죠.
ㅋㅋㅋ 클래스명이 떠오른대
이른 최적화는 만악의 근원이래요
대충 상상한게 맞군요
그러다 아주 가끔, 우리가 잘못된 산을 오른것 같습니다. 하는 보고가 올라가게 되면 헬게 오픈이지 ㅋㅋ
여기 저기 모가지들이 나뒹굴고... 농담.