Hacker News 의견

• 첫 번째 예제인 객체 풀을 보면서, 경고 없이 가능하다는 점에 놀라움

  • 이 API는 제네릭 이전에 존재했기 때문에 any를 사용함
  • Golang이 원칙적으로는 강한 타입 시스템을 갖고 있지만, 실제로는 타입 시스템을 벗어나는 API가 많음
  • 타입 시스템이 정말 유용한지 의문이 생김
  • 초기화된 기본값으로 값을 재설정하는 API가 없다는 점도 주목할 만함

• 성능 가이드는 할당을 최소화하여 GC 시간을 줄이도록 권장함

  • GC 마크 단계가 시간을 소모하며, 긴 수명의 할당을 피하는 것이 좋음
  • 짧은 수명의 할당은 GC 시간에 거의 영향을 미치지 않음
  • 실제 앱에서는 GC를 피하는 것이 거의 불가능하며, GC 마크 시간을 줄이는 것이 더 효과적임

• 추가적으로...

  • Go 최적화 가이드
  • Uber Go 가이드
  • 6개월 동안 여러 언어 프로젝트를 전환하면서 중요한 것들을 기억하는 것이 어려움

• 제로 카피는 과소평가됨

  • Go의 인터페이스는 제로 카피 코드를 작성하기에 적합하지만 주의가 필요함
  • 메모리 할당과 이동에 많은 시간이 소요됨을 종종 깨달음

• GOMEMLIMIT는 여러 번 도움을 줌

  • 컨테이너화된 프로덕션에서 유용하며, CI에서 메모리 부족 문제를 해결함
  • nogo로 전환하여 golangci-lint 문제는 해결됨

• 최적화가 필요한 프로젝트에 대한 호기심

  • 예: 구조체 필드 정렬

• 객체 풀링 문서를 보면서 sync 같은 패키지를 제네릭으로 만들 계획이 있는지 궁금함

• Golang이 C와 구조체 정렬에서 비슷하다는 점에 놀라움

• "구조체 Data가 [1024]int 배열을 포함하고 있으며, 이는 4KB임"

  • 32비트 아키텍처를 기본으로 사용하는 사람이 있는지 의문

• sync.Pool을 사용하여 자신을 속일 수 있음

  • pprof는 벤치마크에서 할당이 없기 때문에 좋아 보이지만, 실제 메모리 사용량은 증가함
  • 실제 세계에서의 이점을 측정하는 것이 중요함