현재 CMake, GCC, Unix Make만 사용 가능한 환경에 갇혀 있어서 빌드가 왜 느린지에 대한 상세 정보를 얻는 게 거의 불가능함, 소스에서 빌드 폴더로 파일 복사 같은 복잡한 빌드 단계, 여러 언어(C, C++, Fortran, Python), 커스텀 CMake 스텝 등으로 엉망인 빌드임, 만약 이 툴이 이런 혼란스러운 환경에서도 잘 동작한다면 정말 많은 것을 배울 수 있을 것 같음
tsoding이 https://github.com/tsoding/nob.h에서 크로스 플랫폼 빌드를 위한 싱글 헤더 C 라이브러리를 작성했음, 오직 cc만 필요함, GDB 프로파일링 툴을 사용하여 빌드 단계를 살펴볼 수 있음, 멋진 아이디어라고 생각함, 아마 이 글쓴이에게는 맞지 않을 수도 있지만, 여러 언어를 다뤄야 한다면 Nix가 훌륭한 빌드 툴임
내 게임 엔진의 컴파일 시간을 줄여보려고 시도할 때, 컴파일된 결과물의 크기를 대체 척도로 썼었음, 워낙 벽시계 기준 시간이 불안정해서 빌드마다, 심지어 다른 머신에서도 결과가 동일한 바이너리 크기 측정이 오히려 다루기 더 쉬웠음, 100% 일치하지는 않지만 실질적으로 도움이 되었음
비슷한 문제를 겪고 있음, 종종 CMake가 수정하지도 않은 파일까지 다시 컴파일하는 걸 본 경험이 있음, 예를 들어 인터페이스 변경 없이 .cpp를 조금만 고쳐도 전혀 독립적인 오브젝트까지 재컴파일 되는 현상임, CMake가 실제 파일들보다 더 강하게 종속성을 만드는 게 아닌지 가끔 궁금해짐, 그래서 빌드 시간이 괜히 길어지는 것 같다는 의문 있음
블로그 작성자에게 제안하겠음, macOS 앱 빌드를 기록한 gif 이미지를 페이지 상단, 헤더 바로 아래에 보여주면 좋겠음, 만든 결과물을 먼저 보여주고 그 뒤에 설명을 붙이는 흐름이 보기 좋음
좋은 제안임, 바로 반영해서 블로그 업데이트했음
이 프로젝트 정말 마음에 듦, 비슷한 시도를 2018년에 strace와 dtruss, https://buildinfer.loopperfect.com/를 써서 BUCK 파일 자동 생성 같은 일을 해봤음, graphviz, perfetto.dev 등으로 시각화함, 정식 제품으로 패키징하지 못한 게 아쉽지만 컨설팅에서 원인 진단과 BUCK/Bazel 전환에 큰 도움 받았음, 최근에도 더 넓은 적용을 고민하며 다시 돌아보고 있음, 이 방식에 본질적인 기술적 도전 과제도 있긴 함: 시스템콜 로그가 디스크에 기록되면 수십~수백 GB 정도 크기가 커짐(예: llvm은 50GB, 어떤 경우 100GB 넘음), https, IPC 같은 빌드 단계까지 전부 잘 처리해야 함(예전에 어떤 고객은 Perl로 Firebird DB에서 코드를 빌드할 때마다 끌어오기도 했음), 런타임 분석이라는 특성 때문에 빌드 설정마다 분석을 반복해야 한다는 점도 있음
궁금해서 묻겠음, 시스템콜 로깅은 어떻게 했음? LD_PRELOAD 같은 트릭이나 eBPF 필터링 썼는지 궁금함
멋지다고 생각함, 이런 시각화 없어서 놓치는 문제들이 정말 많다고 느꼈음, 10년 전에 Mozilla 빌드 시스템 최적화할 때 이런 툴이 있었으면 정말 도움이 됐을 것 같음, 글에서는 실제로 어떤 문제를 찾았는지 좀 더 알려줬으면 더 좋았을 것 같음
(작성자) 고마움, Mozilla 엔지니어와의 통화가 갑자기 끝나서 어떤 문제 찾았는지 자세하게 듣지는 못했음, 직접 확인해보고 싶음
CMake로 관리하는 C++ 프로젝트에서 빌드 퍼포먼스 시각화에 ninjatracing과 Clang의 -ftime-trace를 성공적으로 사용해본 경험 있음, 추가로 ClangBuildAnalyzer를 쓰면 컴파일러가 어디서 시간을 쓰는지 더 세밀히 분석할 수 있음
정말 멋지다고 생각함, 혹시 오픈소스 계획이 있는지 궁금함, 비슷한 걸 만들고 있어서 협력하고 싶음
Windows에서 Visual C++ 컴파일러를 사용한다면 vcperf도 추천함, VS2022에 기본 포함되어 있거나 깃허브에서 직접 빌드해서 사용할 수 있음, UBT나 CMake로 생성된 프로젝트에도 적용해봤음, 빌드 병렬화 품질을 직접 판별할 수 있는지는 기억 안 나지만, 컴파일러 프론트엔드 정보를 쉽게 볼 수 있음, 특히 자주 포함되거나 본질적으로 무거운 헤더 파일을 쉽게 찾을 수 있음
Incredibuild도 추천함, 무료 버전만으로도 빌드를 시각화해서 병목 구간을 파악하기에 충분함
일반적으로 간과되지만, 빌드 시스템의 “baked in”된(사전 계산된) 빌드 로직이 실제로 어떤 변경에 영향을 받는지 세밀하게 추적되지 않는다는 점이 중요한 관찰임, 예를 들어 ninja에서는 일부 빌드 로직이 미리 입력되어 있어서 속도가 빠름, 나는 Xerces-C++를 ninja(CMake로 설정)와 build2(설정 및 변경 추적을 빌드에서 다루는 툴)로 각각 풀빌드 벤치마크를 했는데 ninja는 3.23초, build2는 3.54초임, CMake가 만드는 파일 일부를 유지한 채로 반복해서 빌드하면 3.28초로 다운됨, 참고로 CMake만의 설정 단계는 4.83초임, 풀스택의 CMake+ninja 빌드는 실제로 8초 정도 소요됨, 보통 이걸 라이브러리로 쓸 때 실제로 겪게 되는 시간임
kbuild가 Make에서 각 타겟을 더미 파일에 의존하도록 해 CFLAGS같은 옵션 변경 시 제대로 반영함, Make를 ninja처럼 쓰기 위해 전체 빌드 그래프를 각 Make 프로세스에 안 넣도록 설계되어 있음, 실제로 어떻게 비교될지 궁금함
Instruments를 빌드하는 동안 실행해서 어떤 프로세스가 언제 뭘 하는지 파악하는 식으로 비슷한 시도를 한 경험 있음, 단점은 빌드가 오래 걸리면 Instruments가 버벅임, 프로세스 트리 필터링이 안돼서 불편하지만 Twitter의 iOS 코드 빌드 시간 대폭 줄일 때 큰 도움이 됐음, 최근에는 Instruments의 “All Processes” 트레이싱이 깨져서 더 이상 이 방법이 불가능해진 상태임
정말 멋지게 느껴짐, 혹시 지금 바로 테스트할 수 있는 macOS 버전 있는지 궁금함, Rust나 C++/Swift 작업에도 써보고 싶음
버그 픽스 후에 다음 베타 테스트 유저로 macOS 버전을 배포 계획 없음, (아티클 하단에서) 신청하면서 이 댓글 언급해주면 꼭 베타 그룹에 포함해주겠음
Hacker News 의견
현재 CMake, GCC, Unix Make만 사용 가능한 환경에 갇혀 있어서 빌드가 왜 느린지에 대한 상세 정보를 얻는 게 거의 불가능함, 소스에서 빌드 폴더로 파일 복사 같은 복잡한 빌드 단계, 여러 언어(C, C++, Fortran, Python), 커스텀 CMake 스텝 등으로 엉망인 빌드임, 만약 이 툴이 이런 혼란스러운 환경에서도 잘 동작한다면 정말 많은 것을 배울 수 있을 것 같음
tsoding이 https://github.com/tsoding/nob.h에서 크로스 플랫폼 빌드를 위한 싱글 헤더 C 라이브러리를 작성했음, 오직 cc만 필요함, GDB 프로파일링 툴을 사용하여 빌드 단계를 살펴볼 수 있음, 멋진 아이디어라고 생각함, 아마 이 글쓴이에게는 맞지 않을 수도 있지만, 여러 언어를 다뤄야 한다면 Nix가 훌륭한 빌드 툴임
내가 GCC 플러그인으로 컴파일 시간 트레이싱/프로파일링 도구를 직접 만들었음, 혹시 관심 있다면 참고: https://github.com/royjacobson/externis
내 게임 엔진의 컴파일 시간을 줄여보려고 시도할 때, 컴파일된 결과물의 크기를 대체 척도로 썼었음, 워낙 벽시계 기준 시간이 불안정해서 빌드마다, 심지어 다른 머신에서도 결과가 동일한 바이너리 크기 측정이 오히려 다루기 더 쉬웠음, 100% 일치하지는 않지만 실질적으로 도움이 되었음
비슷한 문제를 겪고 있음, 종종 CMake가 수정하지도 않은 파일까지 다시 컴파일하는 걸 본 경험이 있음, 예를 들어 인터페이스 변경 없이 .cpp를 조금만 고쳐도 전혀 독립적인 오브젝트까지 재컴파일 되는 현상임, CMake가 실제 파일들보다 더 강하게 종속성을 만드는 게 아닌지 가끔 궁금해짐, 그래서 빌드 시간이 괜히 길어지는 것 같다는 의문 있음
블로그 작성자에게 제안하겠음, macOS 앱 빌드를 기록한 gif 이미지를 페이지 상단, 헤더 바로 아래에 보여주면 좋겠음, 만든 결과물을 먼저 보여주고 그 뒤에 설명을 붙이는 흐름이 보기 좋음
이 프로젝트 정말 마음에 듦, 비슷한 시도를 2018년에 strace와 dtruss, https://buildinfer.loopperfect.com/를 써서 BUCK 파일 자동 생성 같은 일을 해봤음, graphviz, perfetto.dev 등으로 시각화함, 정식 제품으로 패키징하지 못한 게 아쉽지만 컨설팅에서 원인 진단과 BUCK/Bazel 전환에 큰 도움 받았음, 최근에도 더 넓은 적용을 고민하며 다시 돌아보고 있음, 이 방식에 본질적인 기술적 도전 과제도 있긴 함: 시스템콜 로그가 디스크에 기록되면 수십~수백 GB 정도 크기가 커짐(예: llvm은 50GB, 어떤 경우 100GB 넘음), https, IPC 같은 빌드 단계까지 전부 잘 처리해야 함(예전에 어떤 고객은 Perl로 Firebird DB에서 코드를 빌드할 때마다 끌어오기도 했음), 런타임 분석이라는 특성 때문에 빌드 설정마다 분석을 반복해야 한다는 점도 있음
멋지다고 생각함, 이런 시각화 없어서 놓치는 문제들이 정말 많다고 느꼈음, 10년 전에 Mozilla 빌드 시스템 최적화할 때 이런 툴이 있었으면 정말 도움이 됐을 것 같음, 글에서는 실제로 어떤 문제를 찾았는지 좀 더 알려줬으면 더 좋았을 것 같음
CMake로 관리하는 C++ 프로젝트에서 빌드 퍼포먼스 시각화에 ninjatracing과 Clang의
-ftime-trace를 성공적으로 사용해본 경험 있음, 추가로 ClangBuildAnalyzer를 쓰면 컴파일러가 어디서 시간을 쓰는지 더 세밀히 분석할 수 있음정말 멋지다고 생각함, 혹시 오픈소스 계획이 있는지 궁금함, 비슷한 걸 만들고 있어서 협력하고 싶음
Windows에서 Visual C++ 컴파일러를 사용한다면 vcperf도 추천함, VS2022에 기본 포함되어 있거나 깃허브에서 직접 빌드해서 사용할 수 있음, UBT나 CMake로 생성된 프로젝트에도 적용해봤음, 빌드 병렬화 품질을 직접 판별할 수 있는지는 기억 안 나지만, 컴파일러 프론트엔드 정보를 쉽게 볼 수 있음, 특히 자주 포함되거나 본질적으로 무거운 헤더 파일을 쉽게 찾을 수 있음
일반적으로 간과되지만, 빌드 시스템의 “baked in”된(사전 계산된) 빌드 로직이 실제로 어떤 변경에 영향을 받는지 세밀하게 추적되지 않는다는 점이 중요한 관찰임, 예를 들어 ninja에서는 일부 빌드 로직이 미리 입력되어 있어서 속도가 빠름, 나는 Xerces-C++를 ninja(CMake로 설정)와 build2(설정 및 변경 추적을 빌드에서 다루는 툴)로 각각 풀빌드 벤치마크를 했는데 ninja는 3.23초, build2는 3.54초임, CMake가 만드는 파일 일부를 유지한 채로 반복해서 빌드하면 3.28초로 다운됨, 참고로 CMake만의 설정 단계는 4.83초임, 풀스택의 CMake+ninja 빌드는 실제로 8초 정도 소요됨, 보통 이걸 라이브러리로 쓸 때 실제로 겪게 되는 시간임
Instruments를 빌드하는 동안 실행해서 어떤 프로세스가 언제 뭘 하는지 파악하는 식으로 비슷한 시도를 한 경험 있음, 단점은 빌드가 오래 걸리면 Instruments가 버벅임, 프로세스 트리 필터링이 안돼서 불편하지만 Twitter의 iOS 코드 빌드 시간 대폭 줄일 때 큰 도움이 됐음, 최근에는 Instruments의 “All Processes” 트레이싱이 깨져서 더 이상 이 방법이 불가능해진 상태임
정말 멋지게 느껴짐, 혹시 지금 바로 테스트할 수 있는 macOS 버전 있는지 궁금함, Rust나 C++/Swift 작업에도 써보고 싶음
버그 픽스 후에 다음 베타 테스트 유저로 macOS 버전을 배포 계획 없음, (아티클 하단에서) 신청하면서 이 댓글 언급해주면 꼭 베타 그룹에 포함해주겠음
아직 어떤 OS도 퍼블릭 릴리즈는 없는 것 같고, 얼리 억세스 신청만 가능한 상태임