모든 사람이 소프트웨어를 더 빠르게 실행시키기 위해 어떤 아이디어도 시도 할 수있는 기간을 계획하고 있습니까?

때로는 소프트웨어 성능 트릭이 방법론과 철저한 검색에서 발견됩니다. 때로는 미친 아이디어를 시도하기 위해서는 다양한 생각과 용기가 필요합니다. 때때로 아이디어는 시작일 뿐이며 많은 노력이 필요합니다.

모든 사람이 다른 아이디어를 시도하여 현재 작업중인 소프트웨어의 성능을 향상시킬 수있는 기간을 조성하는 방법은 무엇입니까? 팀의 모든 직원은 소프트웨어에 대해 최소한 몇 개월의 경험이 있으며 매우 능숙합니다.

다양한 생각이 소프트웨어 성능을 향상시키는 방법을 찾는 데 도움이된다는 데 동의하십니까? 왜? 왜 안돼?

최적화 기술을 빠르게 시험해볼 수있는 기술은 무엇입니까? 트라이 아웃에서 좋은 결과를 얻으려면 빠른 코딩 속도가 필요합니까?

마지막으로, 느슨해 질 가능성없이 좋은 결과를 얻으려면 얼마나 많은 "시간"을 할당해야합니까?

"뭔가를 더 빠른 방법"이 있음을 증명하기 위해 실험이 필요한가? (2011-06-07 추가)

관련 :

• 영리한 방식으로 팀의 수준을 향상시키기위한 전략은 무엇입니까?
• 코드 해킹은 언제 나빠 집니까?

( 현상금 목적으로 만 -2011/06/07 팀 크기가 2-4 개발자, 전담 QA입니다. 개발자에 의해 수행 모든 코드, 단위 테스트 및 성능 테스트. 때문에 프로젝트의 특성, 프로파일 결과를 보여주는 데 유용합니다 단일 병목 현상이 나타나지 않더라도 비례 실행 시간)

가장 좋은 방법은 프로파일 러로 핫스팟을 식별하고 팀으로서 핫스팟을 수정하는 방법에 대해 논의하는 것입니다.

개선점을 측정하고 문서화 할 수 있어야하며 (따라서 추측 만하는 것이 아님) 팀으로서이를 수행하면 사람들이 수정중인 내용과 방법을 알 수 있습니다.

코드베이스에서 프로그래머가 해킹을 시도하면 아이디어를 시험해 볼 수 있으며 진행중인 작업과 작동 여부를 제어 할 수 없습니다.

프로그래머는 똑똑하고 독창적 인 경향이 있습니다 (프로그래밍에 능숙하기 위해서는 전제 조건이므로). 문제를 해결할 때 항상 다양한 아이디어를 시험해 보는 것이 좋습니다. 그러나 성능을 개선하려고 할 때 기억해야 할 두 가지 사항이 있습니다 ( "성능"이라고 가정하면 실행 속도를 줄입니다).

• 알고리즘 최적화는 다른 것보다 훨씬 잘 작동하는 경향이 있습니다. 사소한 예로서, 당신이 당신의 bubbleort 구현에 무엇이든간에, 충분한 수의 quicksort의 구현은 결국 더 빠를 것입니다.
• 성능 관련 작업을 수행하는 것은 측정 (프로파일)하고 결과에 기반한 모든 작업을 수행하지 않는 한 완전히 무의미합니다.

나의 주요 요점은 야생 실험 을 시작하기 전에 이러한 것들에 관해 모든 사람과 같은 페이지에 있는지 확인하는 것이 중요하다는 것 입니다. 경험이 부족한 동료가 절대 효과가없는 일을 시도하고 있다는 것을 알아 낸 것은 항상 부끄러운 일입니다.

슬프게도, 나는 경험에서 말할 수 없습니다. 하지만 Atlassian은 직원들이 원하는대로 자신의 일을하고 아이디어를 일종의 파티 분위기로 표현할 수있는 하루 를 보낸다고 들었습니다 . 분명히 그들에게 잘 밝혀졌습니다. 그러나 Andersen에 동의하고 성능에 관해서는 창의적이고 즉시 사용 가능한 아이디어는 덜 중요하며 프로세스에 가장 많은 시간이 걸리는 프로파일 링은 중요하지 않습니다. 시스템을 프로파일 링 한 후에는 프로세스의 중요한 섹션 속도를 높이는 방법에 대한 아이디어를 모든 사람에게 제공 할 수 있습니다. 그들이 아이디어를 제시 한 후에는 어떤 아이디어를 시도 할 것인지 선택할 수 있습니다.

우리의 이전 팀 중 일부에서 성공적으로 수행 한 한 가지 방법은 Deep Dives의 개념을 갖는 것입니다. 몇몇 사람들은 회의실에서 모여서 사용자 시나리오를 결정하고 코드를 단계별로 실행하거나 프로파일 러 로그를 살펴보기 시작합니다. 어떤 경우에는 데이터에 병목 현상이 분명해 보였으므로 회의론자들에게 자신의 코드에 실제로 성능 문제가 있음을 설득 할 수있었습니다! 이를 성공적으로 달성하기 위해 우리가 따라야 할 몇 가지 핵심 교리가있었습니다.

1. 병목 현상이 의심되는 중요한 시나리오 또는 코드 경로에 집중하십시오. 최적화 할 필요가없는 것을 최적화하는 데 팀을 낭비하지 마십시오 (파산하지 않은 경우 ...)
2. 그룹을 작게 유지하고 코드를 가장 잘 아는 사람들에게 집중하십시오. 기능에 대한 테스터 및 프로그램 관리자를 포함시키는 것을 잊지 마십시오. 주요 통찰력을 가지고 있으며 더 나은 테스트 방법에 대한 정보를 수집하거나 참여함으로써 이점을 얻을 수 있습니다.
3. 영역 소유자가 해당 영역에 대한 높은 수준의 아키텍처 블록 수준 다이어그램 및 개요를 제공하도록하여 세션을 시작하십시오. 주요 구성 요소는 무엇이며 그 구성 요소를 간단히 설명합니다. 코드를 파고 들자 블록 다이어그램이 현실을 반영하지 않은 횟수에 놀랄 것입니다. (실제 인용문 : "우리는 여전히 그 구성 요소를 사용하고 있다는 것을 몰랐습니다. 몇 년 전에 제거했다고 생각했습니다!")
4. 성능 문제 및 성능 문제를 찾을 수 있습니다. 좋은 일입니다. 또한 때로는 중요한 것을 찾을 수 없을 것으로 기대하십시오. 그것도 좋은 일이 될 수 있습니다.
5. 긴 세션이 여러 차례있을 것으로 예상합니다. 이들은 작업 회의입니다. 편안하게 작업하십시오. 모두가 확장 된 스트레칭을 위해 협력 할 수 있으면 훨씬 더 많은 일을 할 수 있습니다.
6. 메모, 좋은 메모를하십시오. 결함 추적 데이터베이스를 사용하는 경우 우선 순위가 낮더라도 즉시 열어보고 문제를 추적하십시오.

전체 팀이 "성능 추진"에 참여하지 않도록하십시오. 이들은 보통 Thorbjørn Ravn Andersen 이 다른 답변에서 언급 한 이유로 경영진이 기대하는 결과를 얻지 못합니다 . 일부 영역에서는 큰 이익을 얻거나 사람들이 익숙하지 않은 다른 영역에서는 회귀를 얻을 수 있으며 "완료"라고 말하는 게 얼마나 많은 이익을 예측 / 추적하기가 어렵습니다. 경영진과의 대화는 쉽지 않습니다.

소프트웨어 속도가 향상되어야하는 이유는 소프트웨어 속도가 느리기 때문입니다. 그렇지 않은 경우 최적화는 시간 낭비입니다. 그러나 무언가가 느리면 작업을 수행하십시오.

... 그리고 작업을 수행하기 위해 다음 두 단계가 있습니다.

1. 작업을 수행하는 기능이 효율적으로 작성되었는지 확인하십시오. 알고리즘이 양호하거나 불량합니까? 효율적인 방식으로 데이터베이스에 액세스하고 있습니까? 한 번 할 수있을 때 100 번 반복됩니까? 코드를 간단하게 검사하면 한 가지 장애물을 찾아서 해결할 수있을뿐 아니라 동시에 더 나은 프로그래머가 될 수 있습니다.

2. 숫자 1에 1 시간 이상을 소비하지 마십시오. 1 시간 내에 문제를 찾을 수 없으면 프로파일 러를 사용하여 해당 지점을 찾으십시오. 문제 지점을 알고 나면 1 번으로 돌아가 다시 식별하여 식별 한 코드를 개선하는 가장 좋은 방법을 찾을 수 있습니다.

일반적으로 (**) 실험을 통해 더 나은 성능을 얻지 못합니다.

당신은 그것을 얻을

• 간단하고 효율적인 디자인으로 시작하는 방법을 알고 있습니다. 이 부분이 잘못되면 실험에 큰 차이가 없습니다. 예를 들어, 코드 생성기 사용시기를 알리는 방법이 성공적인 설계 방법이라는 것을 알고 있습니다.

• a) 백분율로 비싼 활동을 찾고 b) 더 나은 것으로 대체 할 수있는 활동을 찾아서 소프트웨어를 조정하는 방법을 알고 있습니다. 모두가 당신이 "프로필러를 사용해야한다"는 것을 알고 있지만 충분하지 않습니다.

다른 질문에 대한 답을 확인하십시오.

** 예외는 그래픽 렌더링, 프로세서 파이프 라인 또는 CUDA 동작과 같은 하드웨어 의존적 코드이거나 네트워크 또는 DB 프로토콜 실험과 같이 하드웨어를 사용하는 가장 좋은 방법에 익숙해 져야합니다.

ADDED : 큰 시스템의 많은 프로그래머들이 놀라운 것을 발견했습니다. 완벽하게 구성된 대규모 프로그램에는 크고 눈에 띄지 않는 성능 문제 가있을 수 있으며 프로파일 러는 일상적으로 현지화되지 않았기 때문에 찾을 수 없습니다. 비록 프로그램이 최상의 스타일로 수행 되더라도 프로그램의 일반적인 구조의 일부입니다.

구체적인 예를 들기 위해 다음은 작업을 수행하는 소스 코드 가있는 프로그램 입니다 (C ++로). 내가 작업 한 실제 C 프로그램에서 추출되었습니다.

그것은 의도 된 일을하지만 실제로 시간의 일부는 필요 하지 않습니까? 속도를 얼마나 높일 수 있습니까?

글쎄, 프로그램의 첫 번째 버전에서 완벽하게 합리적으로 보이고 비 로컬 (프로파일 러에게는 보이지 않음)의 시간이 33.3 %를 소비했습니다. 그것이 교체되었을 때, 그 시간은 절약되었고 그것은 프로그램의 두 번째 버전이었습니다.

프로그램의 두 번째 버전에서는 제거 할 수있는 다른 프로파일 러 (모든 프로파일 러에게는 보이지 않음)가 16.7 %의 시간이 걸렸습니다. 그것을 제거하면 버전 3이되었습니다.

버전 3에서는 13 %가 제거되었습니다. 남은 것 중 66 %가 제거되었습니다. 그 후 남은 것 중 61 %가 제거되었습니다!

그런 다음 마지막으로 남은 것 중 98 %가 제거되었습니다!

그래서 큰 그림은 무엇입니까? 원래 프로그램에서 사용한 1000 회주기 중 몇 개가 제거 되었습니까? 998!

모든 프로그램은 서로 다르지만 필자의 경험에 따르면 모든 대형 프로그램에는 프로파일 러가 찾을 수없고 수동 샘플링이 수행 할 수있는 일련의 시간 문제가 있으며 프로그래머가 실제로 최대 성능을 얻으 려면 제거 할 수 있습니다. 큰 속도 향상을 위해.