코드 투명도가 애플리케이션 성능을 저하시키는 것입니까?

오늘날의 코드가 점점 복잡 해짐에 따라 코드를 유지 보수 할 수 있도록 설계해야합니다. 읽기 쉽고 이해하기 쉽습니다.코드 투명도가 애플리케이션 성능을 저하시키는 것입니까?

Winamp 나 고성능 프로그램이 필요한 일부 게임과 같이 몇 년 전에 실행 된 프로그램을 기억할 수는 없지만 486 100 MHz는 mp3를 재생하지 않기 때문에 모든 CPU 사이클을 소모 한 아름다운 mp3 플레이어.

이제 Media Player (또는 무엇이든)를 실행하고 mp3를 재생하고 내 4 개의 코어 중 하나의 25-30 %를 섭취합니다. 어서! 486이 그렇게 할 수 있다면, 재생은 어떻게 그렇게 많은 프로세서를 사용할 수 있습니까?

저는 개발자로서 나에게 항상 익숙합니다. 코드를 간단하게 유지하고 성능을 위해 중간에 최적화하지 마십시오. 우리가 "가능한 한 최소의 CPU를 사용하려고 노력했다"에서 ""이 너무 많은 CPU를 사용하지 않는다면 ""으로 변경된 것 같습니다.

그래서 최적화를 무시하여 성능을 저하시키고 있다고 생각합니까?

출처

2009-07-22 Jorge Córdoba

미디어 플레이어의 코드 선명도가 의심 스럽습니다. –

이것이 답할 가치가있는 질문이라고 생각하지만, 왜 응용 프로그램이 느린지에 대한 첫 번째 추측은 개발자가 분명한 코드를 작성해야하기 때문입니다. :) 일반적으로 나는 많은 사람들이 일반적인 응용 프로그램의 느린 속도에 대해 일반적인 '소프트웨어 팽창'(다소 모호한 용어)을 사용한다고 생각합니다. – Falaina

내가 원인을 알 수는 없지만 누군가 (stackoverflow 포함) 어디서나 물어 본다. 성능 향상을 위해 사용해야합니까? 대답은 거의 항상 "아니오, 문제가 발생할 때까지 성능에 신경 쓰지 않습니다"입니다. 따라서 우리는 기능으로 결코 버그로 성능을 가져옵니다 ... –

코드를 삭제해도 성능이 저하되지 않습니다. 나쁜 코드로 인해 성능이 저하됩니다.

출처

2009-07-22 23:36:03

잘 넣어. 깨끗한 알고리즘은 "조정 된"잘못된 알고리즘보다 성능이 우수합니다. GUI 애플리케이션의 경우 일부 개발자는 데이터 및 이벤트 중심의 사용자 인터페이스가 어떻게 조립되는지 이해하지 못하고 "무차별 대항"대안이 사용자가 묘사하는 결과를 낳습니다. 이는 코드 명확성이 아니라 코드 순진입니다. –

개인적으로 나는 항상 성능과 유지 관리 간의 균형을 위해 노력합니다. 우리는 오랫동안 CPU 시간이 비싸고 프로그래머는 싸지 만 사용자와 개발자는 모두 같은 소프트웨어가 더 새롭고 빠르게 실행되는 새로운 버전에서 더 오래 걸리는 동일한 작업을 찾지 못한다 하드웨어 ... 그래서, 주관적으로, 네, 일부 회사는 다른 방향으로 너무 멀리 갔다고 생각합니다.

출처

2009-07-22 23:38:31 Adrien

성능이 유지 보수성과 관련이 있다고 생각합니다. –

대부분 그렇습니다.하지만 제가 (가난하게) 얻고있는 것은 당신이 당신 자신의 대답에서 지적한 것과 더 가깝습니다. 나는 "슈퍼 유지 보수가 가능한"코드를 보았습니다. 코드는 느리지 만, 적어도 저에게는 따라 가기가 더 어려웠습니다. 내가 말했듯이, "균형". 80/20 규칙을 오용하기 위해 대부분의 앱은 최고의 성능을 필요로하지 않지만 객체 지향성이 보편화되면서 애플리케이션은 (사용자 관점에서 볼 때) 적어도 느려지고 부풀어 오르는 반면 하드웨어는 속도가 계속 향상됩니다. 성능 불균형은 어디서 오는가? – Adrien

개발자는 응용 프로그램을 최적화하는 것을 두려워해서는 안됩니다. 오늘의 애플 리케이션의 팽창과 느린 속도는 지독합니다.

출처

2009-07-22 23:39:32

++ 반복적 인 반복을 반복하지 말고, 당신 말이 맞습니다. http://stackoverflow.com/questions/926266/performance-optimization-strategies-of-last-resort/927773#927773 –

개발자는 최적화를 두려워해야합니다. 최적화는 더/더 나은 기능, 버그 수정, 유용성 테스트 등과 같이 수행해야하는 모든 작업과 함께 우선 순위를 지정해야합니다. 개발자는 제품 소유자가 아니라면 최적화를 결정하는 사람이되어서는 안됩니다. – nicholaides

최적화는 다른 모든 작업과 함께 우선 순위를 지정해야하지만 개발자가 표준 작업 과정으로 개발할 때 항상 최적화를 구현해야합니다. 우리는 비 최적 코드를 의도적으로 작성하면 안됩니다 (압도적 인 이유없이). 제품 소유자는 개발 세부 사항을 망칠 필요가 없습니다. –

특히 mp3 플레이어에 관해서는, 당신은 아마 같은 것으로 비교하지 않을 것입니다. 오래된 486 MP3 플레이어는 거의 재생하지 못했지만 mp3를 재생합니다. Media Player는 멋진 효과, 에어로 인터페이스 및 그 모든 것들을하는 cruft의 전체 bucketload를 운반합니다. 아마 마이크로 소프트가 당신에게 열거하고있는 것을 알려주기 위해 아마 집이나 다른 십여 곳의 다른 곳으로 전화를 걸고있는 것은 말할 것도 없다.

사실 나는 이것이 더 일반적으로 우리가 접했던 일종의 UI 경험이라고 생각한다. 오늘날 CPU와 메모리면에서 모두 가격을 기대합니다. 코드 구조화로 인한 추가 오버 헤드보다 훨씬 더 중요 할 것입니다. (그리고 우리 컴파일러는 10 년 전보다 훨씬 영리합니다. 그래서 기계 코드 수준에서 요소가 될지 의심 스럽습니다.)

출처

2009-07-22 23:40:16 Cruachan

그건 내가 생각한거야. iTunes는 비주얼 라이저없이 9x - 10x의 CPU를 사용합니다. 그리고 그것은 필터 (EQ 등)를 사용하여 486 일 동안 많이 사용되지 않은 사운드를 향상시킵니다. – Jarrod

I 사실과 반대되는 것을 발견했습니다. 읽고 사용하기에 가장 간단한 코드는 내 경험상 전반적으로 가장 성능이 좋은 경향이 있습니다. 읽기 쉽지 않은 이상한 장소에서 성능 병목 현상이 발생하는 경향이있는 거대한 진흙 구덩이는 제거하거나 리팩토링 할 수 없으므로 그대로 방치됩니다.

출처

2009-07-22 23:40:23 Lee

++ 더 이상 동의하지 못했습니다 .http : //stackoverflow.com/questions/926266/performance-optimization-strategies-of-last-resort/927773#927773 –

나는 hairballs라고 부르는 것을 선호하지만 +1 – kenny

멋진 코드는 빠른 코드 일 수 있습니다. 문제는 여러 가지가 될 수 있습니다.

고급 언어는 개발 시간을 크게 단축하지만 프로세서 시간을 낭비 할 수 있습니다.다수의 응용 프로그램에 대해 이것은 대단한 트레이드 오프입니다.
프로그래머는 예전처럼 알고리즘에 대해 교육받지 못했습니다. 이것은 사람들이 자신의 언어를 사용하기 때문에 고급 언어와 관련 될 수 있습니다. 삽입 정렬보다 빠른 정렬 대신 sort()를 사용합니다.
응용 프로그램이 훨씬 더 많이 수행됩니다. 나는 미디어 플레이어가 WinAmp의 이전 버전보다 더 많은 기능을 가지고 있다고 확신한다.

나는 그 빠른 코드가 죽었다고 말하지 않을 것이다. 반례의 경우 운영 체제 코드 (Linux의 O (1) 스케줄러를 염두에 두어야 함)와 물론 게임 코드를 살펴보십시오.

출처

2009-07-22 23:44:52

winamp의 팬이라면 AOL이 WinAmp를 구입 한 후 AOL에서 Justin Frankel 님의 흥미로운 시간에 관한 훌륭한 기사를 읽고 싶을 것입니다.

그의 최신 제품은 Reaper입니다.

최적화는 플랫폼이 오랫동안 고정되어 있고 실제로 배울 수있는 경우에 가장 적합합니다. 이것은 여전히 콘솔 게임에서 발생합니다.

게임용 타이트한 어셈블리 언어를 많이 작성 했으므로 시간이 필요하다는 것을 알 수 있습니다. 동일한 코드를 반복 작성하고 데이터 구조를 변경하여 훌륭한 프레임 속도를 얻으려고합니다.

PC 앱에는 더 이상 그런 압력이 없습니다. 이 가정은 여분의 작업이 희생되는 경우가 거의 없기 때문에 은을 원하는 사람은 빠른 컴퓨터를 구입할 것이라고 가정합니다.

출처

2009-07-22 23:46:28 Nosredna

-1

좋은 컴파일러가 깨끗하고 잘 작성된 소스 코드를 제공하는 경우 빠르고 효율적인 코드를 생성하지 못하는 경우는 없습니다.

이제 어떤 형태의 코드 생성기를 사용하면 생성기의 소스 출력의 "우수성"에 의존하게됩니다. 확실히 과거에는 겉으로보기에는 단순한 작업을 위해 수와 톤의 쓰레기 코드를 생성하는 코드 생성기를 보았습니다. 나는 도구 디자이너가 "모든 것 및 주방 싱크대"질병으로 고통 받고 있다고 생각합니다. 현대 도구는 더 희박해야하지만 큰돈을 줄이기 전에 도구를 확인하는 것이 좋습니다.

여러분이 직접 코드를 작성한다면, 오늘 알고있는 모든 컴파일러는 좋은 코드를 사용하고 최적화되고 빠른 실행 파일을 만들 것입니다. (디버깅을 목적으로하는 모든 최적화를 해제하지 않는 한).

건배, 비 학문적 인 소프트웨어와 내 경험에

-R

출처

2009-07-23 00:13:51 Huntrods

컴파일러 훌륭하지만, 그렇다고해서 스스로 번개처럼 빠른 코드를 생성 할 수있는 것은 아닙니다. 미디어 (오디오 dsp, 비디오, 애니메이션)와 함께 효율적으로 응용 프로그램을 만드는 작업은 여전히 필요합니다. 많은 일. – Nosredna

좋은 성능은 좋은 데이터 구조를 사용하고, 효율적인 알고리즘을 작성하며, 필요 이상으로 작업하지 않고, 프로파일 러를 사용하여 병목 현상을 식별 한 후 코드를 최적화하는 것으로 나타납니다. 좋은 성능은 코드가 얼마나 깨끗한 지와 관련이 있음을 발견하지 못합니다. –

엉터리 알고리즘은 컴파일러를 완벽하게 유지 관리하는 "gee-wiz cool"방법에 상관없이 느려질 것입니다. – Adrien

, 가장 큰 성능 살인자는 겸손한 성능 저하 exacts 각각의 추상화의 많은 레이어의 사용은, 그러나 그들은 결합 복리와 같은 것. 당신이 가격을 지불받을 때까지 각각은 "좋은 일"과 "일을하는 데 권장되는 방법"으로 간주 될 수 있습니다.

특히 이벤트 설정과 같은 무언가를 설정하는 것과 같은 속성 설정은 네트워크 클래스 전체에 걸쳐 계단식 효과가 있습니다.

출처

2009-07-23 17:36:47

이상한 디자인의 코드와 명확한 코드를 혼동하기 쉽습니다. 전자는 종종 유지하기가 어렵고 수수께끼 같은 병목 현상을 일으킬 수 있습니다. 그러나 UML 다이어그램은 아마도 정말 멋지게 보일 것입니다.

출처

2010-05-23 10:52:36 sharkin

코드 투명도가 애플리케이션 성능을 저하시키는 것입니까?

답변

관련 문제