[feat] multithreads 함수 반영

[chae-dahee]

Related issue

#833

기존에 구현되어 있었으나 사용되지 않던 병렬 처리 함수 fetchGitLogInParallel를 적용했습니다.
Git 로그를 가져오는 전체 실행 시간을 단축하고, 응답 시간의 변동성을 줄여 시스템의 안정성과 예측 가능성을 높이는 것을 목표로 합니다.

Work list

• 기존 단일 스레드 getGitLog 함수를 병렬 처리 방식의 fetchGitLogInParallel 함수로 교체했습니다.
• fetchGitLogInParallel 함수 빌드를 위해, parallel 함수 경로를 수정했습니다.

Result

🎯 getGitLog, fetchGitLogInParallel 함수 성능 비교

각 함수 자체의 실행 시간을 순수하게 측정한 결과, 병렬 처리로 인한 속도 향상을 확인했습니다.

• getGitLog (기존): 4.346초
• fetchGitLogInParallel (변경): 3.312초
• 결과: 실행시간이 1.024초 23.6% 단축되었습니다.

🎰 전체 실행 성능 측정

함수 변경 후, 사용자가 Githru를 실행했을 때의 전체적인 성능을 5회 반복 측정했습니다.

ms	getGitLog	fetchGitLogInParallel
1회	39.512	48.151
2회	50.751	42.818
3회	41.385	41.285
4회	37.43	41.404
5회	39.495	39.739

지표	getGitLog	fetchGitLogInParallel	변화율
평균 응답 시간 (ms)	41.715	42.679	+2.31% (증가)
중앙값 (ms)	39.512	41.404	+4.79% (증가)
최소 응답 시간 (ms)	37.430	39.739	+6.17% (증가)
최대 응답 시간 (ms)	50.751	48.151	-5.12% (감소)
표준 편차 (ms)	5.253	3.018	-42.55% (감소)
변동 계수 (%)	12.59%	7.07%	-43.84% (감소)

전체 테스트에서는 평균 응답 시간이 증가했지만, 병렬 처리의 초기 오버헤드 또는 다른 로직과의 상호작용 때문으로 예상됩니다.

fetchGitLogInParallel 함수는 속도 향상보다, 안정성을 향상시키는 데에 목적을 둔 것으로 보입니다.
변동 계수가 43.84% 감소한 부분은 특정 상황에서 급격히 느려지는 스파이크 현상이 줄어들고 일관되고 예측 가능한 응답 시간을 제공할 수 있습니다. gitParallel.ts에서 스레드 개수를 최대 3개로 제한하여, 시스템에 과도한 부하를 주지 않기 위해 설계된 것으로 의도적인 설계로 판단됩니다.

Discussion

성능측정에 사용된 저장소는 microsoft/vscode 입니다.
extension.ts 에서 성능측정에 사용된 console.log 는 제거하는 것이 맞을까요?

[Kyoungwoong]

와우 LGTM🎉🎉🎉🎉
성능개선 너무 멋있습니다!!

고생하셨습니다~~

[SingTheCode]

고생하셨습니다ㅎㅎ 병렬 스레드 함수 적용하면서 유의미한 결과가 나와서 정말 다행입니다ㅎㅎㅎ 개선할 내용은 아니구 '이러면 어떨까?' 정도의 제안으로 가볍게 봐주시면 감사하겠습니다!

로그 수의 케이스를 여러개로 쪼개고 그에 따른 성능 결과를 측정할 수 있다면 좋을 것 같습니다ㅎㅎ
1000개는 무의미한 것 같고, 1만개 10만개 100만개 같은 단위의 더미데이터를 만들고 그에 따른 성능 측정 결과가 포함되면 좋을 것 같아요!

표도 너무 좋고 깔끔합니다! 한번 더 나아가서 그래프로 표현할 수 있다면 더 좋을 것 같다는 생각이 들어요ㅎㅎ 나중에 발표 때 쓰기도 좋을 것 같구요ㅎㅎ

Discussion에서 언급해주신 로그 관련해서 의견드리면 개발 과정에서 남길만한 로그는console.debug로 남기되, console.time 같은 console.log와 같은 레벨의 콘솔타입은 빌드 환경으로 분기해서 개발환경일 때만 찍히게끔 하는 것은 어떨까 의견드립니다ㅎㅎ

로깅을 위한 유틸함수를 만들어서 관리하는 것도 좋을 것 같아요!

[ytaek]

고생하셨습니다ㅎㅎ 병렬 스레드 함수 적용하면서 유의미한 결과가 나와서 정말 다행입니다ㅎㅎㅎ 개선할 내용은 아니구 '이러면 어떨까?' 정도의 제안으로 가볍게 봐주시면 감사하겠습니다!

로그 수의 케이스를 여러개로 쪼개고 그에 따른 성능 결과를 측정할 수 있다면 좋을 것 같습니다ㅎㅎ 1000개는 무의미한 것 같고, 1만개 10만개 100만개 같은 단위의 더미데이터를 만들고 그에 따른 성능 측정 결과가 포함되면 좋을 것 같아요!

표도 너무 좋고 깔끔합니다! 한번 더 나아가서 그래프로 표현할 수 있다면 더 좋을 것 같다는 생각이 들어요ㅎㅎ 나중에 발표 때 쓰기도 좋을 것 같구요ㅎㅎ

Discussion에서 언급해주신 로그 관련해서 의견드리면 개발 과정에서 남길만한 로그는console.debug로 남기되, console.time 같은 console.log와 같은 레벨의 콘솔타입은 빌드 환경으로 분기해서 개발환경일 때만 찍히게끔 하는 것은 어떨까 의견드립니다ㅎㅎ

로깅을 위한 유틸함수를 만들어서 관리하는 것도 좋을 것 같아요!

@chae-dahee 님, 위 내용 이슈로 만들고 해당 PR 은 머지하셔도 좋을 것 같습니다!

[chae-dahee]

@Kyoungwoong @SingTheCode @ytaek
죄송합니다! 제가 실수로 추가 커밋을 올렸다가 Approve가 해제되었습니다. 😭
코드는 원래 코드 + 개발 환경에서만 콘솔이 찍히도록 하는 간단한 코드이니, 괜찮으시다면 다시 한번 Approve 부탁드려도 될까요?

[SingTheCode]

당연하죠!! 고생많으셨습니다ㅎㅎ

[hyemimi]

수고 많으셨습니다 !! 👍🏻👍🏻