मैंने buildprof (GitHub) बनाया है, एक ओपन-सोर्स ट्रेसिंग टूल जो Linux पर सॉफ्टवेयर कंपाइल करते समय समय कहाँ जाता है दिखाता है। यहां ripgrep की एक स्वच्छ कंपाइल का असली समय का वीडियो है: buildprof डेमो देखें। कभी-कभी, कंपाइलेशन धीमा होता है क्योंकि बस बहुत सारा कोड कंपाइल करने के लिए होता है। लेकिन अधिकांश बार नहीं, वहां सुधारने योग्य समस्याएं होती हैं: खराब पैरेललिज़ेशन, दोहराया गया काम, डाउनलोड निर्भरता या एक विशाल कंपाइलर/लिंकर invocation। buildprof सभी को स्पष्ट रूप से दृश्यमान बनाता है, ताकि आप देख सकें कि क्या जांचने और ऑप्टिमाइज़ करने लायक है। आप इसे उस कंपाइल कमांड के आगे buildprof -- लगाकर चलाते हैं जिसे पहले से इस्तेमाल करते हैं: buildprof -- make -j16, buildprof -- cargo build, buildprof -- ninja -C out/target, buildprof -- just build, buildprof -- ./dev/custom-build-script.sh। buildprof उस build कमांड द्वारा लॉन्च किए गए हर प्रक्रिया को रिकॉर्ड करता है, जिसमें उनके उप-प्रक्रिया (और उनके उप-प्रक्रिया… ) शामिल हैं, और उन्हें एक टाइमलाइन पर रखता है। समय बाईं से दाईं ओर जाता है, बार की चौड़ाई अवधि दर्शाती है, और बच्चे प्रक्रियाएं जो भी उन्हें लॉन्च किया है, उसके नीचे दिखाई देती हैं। मुझे buildprof इसलिए बनाया क्योंकि Jarred Sumner के इस ट्वीट, जो Bun JavaScript रनटाइम के मुख्य वास्तुकार हैं, मेरा सिर खाली किए घूम रहा था: विशेष रूप से, दावा कि Bun की नई Rust कंपाइल Linux पर उसकी पुरानी Zig कंपाइल से अधिक than 5 गुना तेज है। मेरा अनुभव रहा है कि Zig प्रोजेक्ट्स आमतौर पर समान जटिलता के Rust प्रोजेक्ट्स की तुलना में बहुत तेजी से कंपाइल होते हैं। वह intuitions मुझे लगा कि एक रहस्य सुलझाने के लिए है। इसे और भी महत्वपूर्ण, फिर भी आसानी से missed, विवरण tweet में: Zig कंपाइल Full LTO का इस्तेमाल करता था, जबकि Rust कंपाइल Thin LTO का इस्तेमाल करता था। कंपाइलर्स आमतौर पर अलग-अलग compilation units को largely अलग-थलग में optimize करते हैं। Link-time optimization (LTO) उन्हें उन सीमाओं के पार optimize करने की अनुमति देता है। Full LTO उन units को एक large optimization job में एक साथ लाता है, जबकि Thin LTO अधिक separation preserve करता है ताकि बहुत सारा work parallel रूप से चल सकता है। पिछले अनुभव से, यह अंतर build time पर विशाल प्रभाव डाल सकता है। tweet ने इसे पास में उल्लेख किया, लेकिन मुझे सोचना था कि headline सुधार में से कितना वास्तव में इसे समझाता है। मैं संख्याओं को reproduce करने की कोशिश शुरू की। संख्याओं को reproduce किया गया। लेकिन अब क्या? मैं Bun 1.3.14 और Bun 1.4.0 की जांच की और Linux x64 CI builds उनकी replay करने के लिए scripts लिखे, एक 6-core, 12-thread Linux VM पर। scripts build steps और उनकी dependencies को preserve किया, एक मशीन पर सब कुछ चलाया। मेरा timing उसी ballpark में था Jarred के: Linux x64 build Zig era 30m06s, Rust era 5m37s। मेरा single-machine CI-profile replay 24m24s 5m40s। ठीक है, तो मेरा मशीन पर भी gap सामने आया। लेकिन दो माप के बीच besides language के अलावा बहुत कुछ बदल गया था; तो क्या वास्तव में जिम्मेदार था? क्या यह Zig compiler था जो सभी extra समय ले रहा था? या शायद यह Full LTO link था? या शायद Bun के build में मुझे भी नहीं सोचा गया था कुछ और था? यही वह जगह है जहाँ मेरा profiling और developer-tools brain kicked in। generalmente, जब मैं यह समझने की कोशिश कर रहा होता हूं कि क्यों कुछ slow है, मुझे एक trace चाहिए: क्या हुआ, कब हुआ और कितना समय लगा। यह बहुत ही रोमांचक होता कि हमारे पास इन builds के लिए एक trace हो, उन्हें एक timeline पर रखना और देखना कि उनका समय वास्तव में कहाँ गया। लेकिन एक build में बहुत सारे अलग-अलग tools शामिल होते हैं, प्रत्येक का अपने विचार होता है कि क्या हो रहा है। मुझे वह रिकॉर्ड करना चाहिए जो मुझे सभी across देखने की अनुमति दे। builds process trees हैं। जब आप cargo build या zig build चलाते हैं, तो यह महसूस होता है जैसे आप एक program चला रहे हैं। build system को यह तय करना होता है क्या rebuild करने की आवश्यकता है, उन pieces के बीच ordering और क्या parallel रूप से चल सकता है। लेकिन generally, यह स्वयं वह सारा work नहीं करता; यह compilers, code generators, archivers, linkers और arbitrary scripts लॉन्च करता है। ये और भी programs लॉन्च कर सकते हैं जो और भी कुछ लॉन्च कर सकते हैं… अलग-अलग build systems उस work को अलग-अलग तरीकों से describe करते हैं। Cargo देखता है crates, Ninja देखता है build edges और CMake दूसरे build system के लिए instructions generate करता है। From the operating