[engine] 성능 최적화를 위한 view와의 메시징 방안 (무한 스크롤 X git log 분할 처리)

[bbanderson]

현상

현재 저희 프로젝트 대부분의 로딩은 git log CLI 명령어가 차지합니다.
임의의 프로젝트 내에서, vscode 터미널을 열고 아래 명령어를 입력해 보시면, githru의 로딩 속도와 유사함을 체감할 수 있습니다.

git --no-pager log --all --parents --numstat --date-order --pretty=fuller --decorate -c

명령어 args 간략 설명

`--no-pager` : 스크롤 없이 모두 출력

`log` : git log

`--all` : 모든 브랜치의 커밋 로그

`--parents` : 각 커밋의 부모 커밋 정보를 표시

`--numstat` : 각 커밋에서 변경된 파일 & 그 변경된 라인 수 표시

`--date-order` : 커밋 날짜 오래된 것부터 정렬

`--pretty=fuller` : 커밋 날짜 등 자세한 정보

`--decorate` : 브랜치 & 태그 정보 출력

`-c` : 변경된 파일의 내용 간략히 출력

명령어 입력 영상

2024-08-07.9.24.17.mov

githru 초기 로딩 영상

2024-08-07.9.25.00.mov

위 명령어는 packages/vscode/src/utils/git.util.ts 파일에 정의된 getGitLog 유틸 함수에서 사용되는 코드인데요.
보시다시피 매우 긴 문자열을 페이징 처리하지 않아서, 시간이 오래 걸립니다.
즉, githru의 첫 실행부터 "모든" 데이터를 한번에 생성하는 것이 로딩(성능저하)의 큰 부분을 차지한다고 볼 수 있습니다.

---

해결 아이디어

저희 엔진팀 성능 최적화 모듈에서는 githru 실사용자의 입장에서 생각해봤을 때, 처음부터 모든 데이터를 보는 것은 설득력이 다소 아쉽다고 생각했습니다.
그래서 초기 실행 시에는 뷰포트 내에서 빠르게 처리 가능한 정도의 양만 제공한 후, 후속 요청에 한해 일정량을 제공하는 무한 스크롤(또는 페이지네이션) 방식이 더 자연스러운 경험이라고 생각하였습니다.(git graph를 비롯한 많은 서비스가 활용하고 있습니다)

그렇다면 view와 engine 사이에 postMessage API 통신이 필요하다는 것이며,

• view
  • 스크롤이 최하단에 도달하면, git log를 더 요청한다.
• engine
  • git log를 이어 붙인 후, 답장을 한다.

이어서 예상되는 개발 내용 또한 다음과 같습니다.

• view&engine 공통
  • 지금까지 log를 얼만큼 받아왔고, 얼마나 더 받아와야 하는지에 대한 값 저장(offset, limit 등 - 용어는 다를 수 있습니다!)
  • 발신/수신
• view
  • 상태관리
  • 스크롤 이벤트
• engine
  • CSM 노드 가공
  • AnalysisEngine 메서드 (재)정의

특히 @seungineer 님, @Sang-minKIM 님께서 view 성능 최적화를 도와주고 계시니 멘션 드립니다!
확인해보시고, 피드백 또는 의견 편하게 부탁드립니다🙇‍♂️
다른 분들께서도 관련하여 의견 있으시다면, 모두 편하게 주셔도 좋을 것 같습니다!

우선 초안 코드 러프하게 작성하여 PR 오픈해보겠습니다!

[bbanderson]

초안 코드 작성의 범위

• view
  • 스크롤 대신 단순 버튼 클릭으로 트리거
  • GlobalDataProvider에서 지금까지 받아온 git log(커밋노드)의 개수를 useState에 저장
  • IDE Port & Message 요청
• engine
  • Message payload 파싱해서 getGitLog 재호출
  • Message 답장

[bbanderson]

view와의 기능 협의

초기 로딩 시, VerticalClusterList, Statistics (하단 스크롤 및 상세 영역)은 분할하여 처리 한다고 해도, TemporalFilter(상단 날짜 드래그 그래프)는 전체를 불러와서 방향이 좋을 것 같습니다. (cc. @seungineer)

사유

• 전체 추이 및 기간 선택은 중요한 기능

개발 방안

• 메시징(현재 이슈) 기술 검토 성공 후, commitDate&differenceStatistics만 따로 전체 처리 가능한지 검토 예정

[ytaek]

git --no-pager log --all --parents --numstat --date-order --pretty=fuller --decorate -c

캬... 명령어까지!!!!!! 친절 그 자체네요 👍👍👍👍👍

명령어 입력 영상

2024-08-07.9.24.17.mov

요건 좀 오해할 수 있는데,
console에 실제 찍게 되면, 백그라운드로 도는것보다 훠~~얼씬 오래 걸립니다 😸
어쨋든, 생각보다는 오래 걸리는 비싼 연산인 것은 맞습니다.

githru 초기 로딩 영상

2024-08-07.9.25.00.mov
위 명령어는 packages/vscode/src/utils/git.util.ts 파일에 정의된 getGitLog 유틸 함수에서 사용되는 코드인데요. 보시다시피 매우 긴 문자열을 페이징 처리하지 않아서, 시간이 오래 걸립니다. 즉, githru의 첫 실행부터 "모든" 데이터를 한번에 생성하는 것이 로딩(성능저하)의 큰 부분을 차지한다고 볼 수 있습니다.

요건, view팀하고 얘기하시면서 같이 분석해보시면 좋을 것 같아요.
엔진부분도 오래 걸리지만, 아마 저걸 다 svgelement 들로 렌더링을 다 하고 난 뒤에 BounceLoader가 사라지기 전까지의 시간도 포함하고 있을꺼라. 어느 부분이 더 크리티컬한지 보는 것도 괜찮겠네요. (뭐 둘다 오래 걸리긴 할껍니다)
이미 view 분석팀은 저거 다 해보셨기 때문에 금방 답해주실듯 👿

해결 아이디어

저희 엔진팀 성능 최적화 모듈에서는 githru 실사용자의 입장에서 생각해봤을 때, 처음부터 모든 데이터를 보는 것은 설득력이 다소 아쉽다고 생각했습니다. 그래서 초기 실행 시에는 뷰포트 내에서 빠르게 처리 가능한 정도의 양만 제공한 후, 후속 요청에 한해 일정량을 제공하는 무한 스크롤(또는 페이지네이션) 방식이 더 자연스러운 경험이라고 생각하였습니다.(git graph를 비롯한 많은 서비스가 활용하고 있습니다)

그렇다면 view와 engine 사이에 postMessage API 통신이 필요하다는 것이며,

• view

  • 스크롤이 최하단에 도달하면, git log를 더 요청한다.

• engine

  • git log를 이어 붙인 후, 답장을 한다.

이어서 예상되는 개발 내용 또한 다음과 같습니다.

• view&engine 공통

  • 지금까지 log를 얼만큼 받아왔고, 얼마나 더 받아와야 하는지에 대한 값 저장(offset, limit 등 - 용어는 다를 수 있습니다!)
  • 발신/수신

• view

  • 상태관리
  • 스크롤 이벤트

• engine

  • CSM 노드 가공
  • AnalysisEngine 메서드 (재)정의

특히 @seungineer 님, @Sang-minKIM 님께서 view 성능 최적화를 도와주고 계시니 멘션 드립니다! 확인해보시고, 피드백 또는 의견 편하게 부탁드립니다🙇‍♂️ 다른 분들께서도 관련하여 의견 있으시다면, 모두 편하게 주셔도 좋을 것 같습니다!

우선 초안 코드 러프하게 작성하여 PR 오픈해보겠습니다!

진행할 내용들 엄청 잘 쪼개주셨네요.
가능하면, 한방에 다 올리지 마시고, 쪼개신 대로 (혹은 더 쪼개서?) 올려주시면 좋을 것 같아요.
굳이 현재 코드를 업데이트 하지 않더라도, 별도의 테스트 파일로 테스트 해볼 수 있도록 하면 더 좋을 것 같긴 합니다.
(이번기회에 jest로 좀 해보시는 것도.. 😄 )

[Sang-minKIM]

초안 코드 작성의 범위

• view

  • 스크롤 대신 단순 버튼 클릭으로 트리거
  • GlobalDataProvider에서 지금까지 받아온 git log(커밋노드)의 개수를 useState에 저장
  • IDE Port & Message 요청

• engine

  • Message payload 파싱해서 getGitLog 재호출
  • Message 답장

view 성능 최적화 팀에서도 무한스크롤이 필요하다는 이야기를 했습니다.
말씀해주신 것처럼 초기에는 스크롤 대신 버튼 형식으로 API통신을 해서 받는 방법 좋습니다.
현재의 방식과는 많이 달라질 것 같아서 engine 팀과 view 팀 함께 회의시간을 잡아서 이야기 나눠보면 좋을 것 같아요 😁

[seungineer]

githru 초기 로딩 영상
2024-08-07.9.25.00.mov
위 명령어는 packages/vscode/src/utils/git.util.ts 파일에 정의된 getGitLog 유틸 함수에서 사용되는 코드인데요. 보시다시피 매우 긴 문자열을 페이징 처리하지 않아서, 시간이 오래 걸립니다. 즉, githru의 첫 실행부터 "모든" 데이터를 한번에 생성하는 것이 로딩(성능저하)의 큰 부분을 차지한다고 볼 수 있습니다.

요건, view팀하고 얘기하시면서 같이 분석해보시면 좋을 것 같아요.
엔진부분도 오래 걸리지만, 아마 저걸 다 svgelement 들로 렌더링을 다 하고 난 뒤에 BounceLoader가 사라지기 전까지의 시간도 포함하고 있을꺼라. 어느 부분이 더 크리티컬한지 보는 것도 괜찮겠네요. (뭐 둘다 오래 걸리긴 할껍니다)

현재는 message를 받는 순간 BounceLoader가 보이지 않게 되고, 이후에 svgelement로 렌더링하는 작업이 진행되고 있습니다.
BounceLoader 애니메이션이 보이는 시간은 온전히 message를 전달 받길 기다리는 시간으로 볼 수 있습니다.

[bbanderson]

@Sang-minKIM 좋습니다!! 조만간 자리 한번 해요😄

한가지 첨언드리자면,

말씀해주신 것처럼 초기에는 스크롤 대신 버튼 형식으로 API통신을 해서 받는 방법 좋습니다.

위에서 제가 말씀드린 버튼 방식은 아직은 기술 검토 단계로서 스크롤 방식을 구현할 수 없기에, 임시 트리거뿐임을 말씀드립니다~!

추후 함께 더 논의하면서 정확한 구현 방식을 나눠보면 좋겠네요ㅎㅎ