[engine] Worker를 활용한 깃 로그 받아오기 #713
Conversation
| // console.time('Single log') | ||
| // const testGitLog = await getGitLog(gitPath, currentWorkspacePath); | ||
| // console.timeEnd('Single log') |
There was a problem hiding this comment.
위 코드는 기존 방식으로 깃 로그를 받아오는 코드입니다. 추후에 사용할 가능성이 있어, 주석으로 처리해두었습니다.
There was a problem hiding this comment.
다시 생각해보니 굳이 살려둘 필요도 없겠네요, 지우도록 하겠습니다~
| output: { | ||
| // the bundle is stored in the 'dist' folder (check package.json), 📖 -> https://webpack.js.org/configuration/output/ | ||
| path: path.resolve(__dirname, "dist"), | ||
| filename: "extension.js", | ||
| // filename: "extension.js", | ||
| filename: "[name].js", |
There was a problem hiding this comment.
(질문) 설정을 이렇게 해두면 extension.js, worker.js 이렇게 두벌 나오는 건가용?
There was a problem hiding this comment.
넵, 정확하십니다!
생성된 worker.js는 추후에 Worker가 특정 개수의 로그를 받아오는데 사용됩니다.
const worker = new Worker(path.resolve(__dirname, './worker.js'), {
workerData: {
gitPath,
currentWorkspacePath,
skipCount,
limitCount,
},
});| @@ -74,7 +75,15 @@ export async function activate(context: vscode.ExtensionContext) { | |||
|
|
|||
| const initialBaseBranchName = await fetchCurrentBranch(); | |||
| const fetchClusterNodes = async (baseBranchName = initialBaseBranchName) => { | |||
| const gitLog = await getGitLog(gitPath, currentWorkspacePath); | |||
| console.time('Multi log') | |||
| const gitLog = await fetchGitLogInParallel(gitPath, currentWorkspacePath); | |||
There was a problem hiding this comment.
혹시 fetchClusterNodes 내에서 await이 걸려있는 getGitConfig나 engine.analyzeGit는 getGitLog보다 시간이 덜 걸릴까요?? 추후에 뭔가 더 많은 곳에서 적용해봐도 좋을 것 같다는 생각이 들어서요!
There was a problem hiding this comment.
네, fetchClusterNodes에서 가장 많은 시간이 소요되는 부분은 getGitLog입니다.
정확히 수치화 하지는 않았지만 getGitLog가 거의 95% 이상의 시간이 소요되고 나머지 getGitConfig, engine.analyzeGit 등에 대한 처리는 커밋이 만개 정도 되지 않는 이상 1초 이내로 소요되었습니다.
| @@ -12,7 +12,8 @@ | |||
| } | |||
| ], | |||
| "simple-import-sort/exports": "error", | |||
| "no-duplicate-imports": "error" | |||
| "no-duplicate-imports": "error", | |||
| "import/no-commonjs": "off" | |||
There was a problem hiding this comment.
이 부분은 사실 초기에 Worker가 빌드되지 않은(dist에 있지 않은) 외부 파일을 실행할 때 발생한 에러를 고치기 위해 삽입한 코드입니다.
import 대신 require를 사용해야해서 위 코드를 삽입했는데 기억은 잘 나지 않지만 require를 사용해도 문제가 해결되지 않았습니다.
해당 문제는 외부 파일(git.worker.ts)를 따로 번들링하여 해결했습니다.
뭔가 말이 많았는데 해당 코드는 오류 해결을 위해 시도하다가 생긴 코드로 지금은 필요없습니다!
삭제하도록 하겠습니다!
| const gitLog = await getGitLog(gitPath, currentWorkspacePath); | ||
| console.time('Multi log') | ||
| const gitLog = await fetchGitLogInParallel(gitPath, currentWorkspacePath); | ||
| console.timeEnd('Multi log') |
There was a problem hiding this comment.
추후(feature 개발이 끝난 이후) 에는 이 부분도 삭제하면 좋겠습니다.
There was a problem hiding this comment.
마지막에 브랜치 병합할 때 삭제하도록하겠습니다
| "--all", | ||
| ]; | ||
|
|
||
| resolveSpawnOutput( |
There was a problem hiding this comment.
os module을 사용하는 경우, multi OS에서의 테스트도 필요합니다.
가끔 os 별로 다른 결과물이 나오는 경우가 있기도 했네요
There was a problem hiding this comment.
공부해보고 테스트 케이스 작성해보겠습니다!
| const { code, error } = status; | ||
|
|
||
| if (code === 0 && !error) { | ||
| const commitCount = parseInt(stdout.toString().trim(), 10); // Buffer를 문자열로 변환 후 숫자로 변환 |
There was a problem hiding this comment.
10 같은 경우는 변수로 extract 해놓는게 좋겠습니다.
|
새로운 branch 생성하여 base branch로 설정하였습니다 |
BeA-Pro
changed the title
Related issue
#712
Result
Worker를 활용해 Git 로그를 병렬로 처리하여 효율적으로 받아왔습니다.
기존의 경우와 성능을 비교한 결과는 다음과 같습니다.
레포지토리 : You-Dont-Know-JS
총 로그 수 : 2320개
싱글 쓰레드 : 1.395초
멀티 쓰레드 : 1.520초
레포지토리 : vitest
총 로그 수 : 4014개
싱글 쓰레드 : 8.728초
멀티 쓰레드 : 5.278초
레포지토리 : jest
총 로그 수 : 8392개
싱글 쓰레드 : 1분 30.557초
멀티 쓰레드 : 43.560초
레포지토리 : React
총 로그 수 : 25138개
싱글 쓰레드 : 3분 34.876초
멀티 쓰레드: 1분 35.492초
레포지토리 : drupal
총 로그 수 : 63567개
싱글 쓰레드 : 1분 49.311초
멀티 쓰레드 : 38.225초
Work list
getLogCount함수를 통해 받아올 총 로그의 수를 받아왔습니다.fetchGitLogInParallel함수를 사용하여 멀티 쓰레드를 활용해 Git 로그를 받아옵니다.getLogCount를 통해 구한 총 로그 수를totalCnt라고 할 때, 각 쓰레드들은totalCnt/쓰레드의 수만큼 로그를 가져오게 됩니다.git.worker.ts는 쓰레드가 실행하는 파일로 각 쓰레드들은 이를 활용하여 할당된 수의 로그를 받아옵니다.Discussion
로그의 내용에 따라 다르겠지만, 로그 수가 2000개 미만인 경우 오버헤드가 적은 기존 방식이 훨씬 빠릅니다.
하지만 이런 작은 로그 수는 멀티 쓰레드를 활용하더라도 일반적으로 1초 이내에 값을 받아오기 때문에 사용자 경험에는 큰 문제가 없습니다.
Result를 보시면 아시겠지만 Worker를 도입함으로써 확실히 성능이 증가된 것을 확인 할 수 있습니다.
그럼에도 불구하고 여전히 많은 시간이 걸린다고 생각합니다. 이를 위해 추가적인 해결책이 필요할 것 같습니다.