بنيت buildprof (GitHub)، أداة تتبع مفتوحة المصدر تُظهر أين تذهب الوقت عندCompile البرمجيات على Linux. هنا فيديو في الوقت الفعلي له Profiling بناء ripgrep النظيف: شاهد عرض buildprof. في بعض الأحيان، تكون عملياتCompile بطيئة ببساطة لأن هناك الكثير من الكود الذي يجب Compile. ولكن في معظم الأحيان، هناك مشاكل يمكن حلها: ضعف التوازي، عمل متكرر، تنزيلات الاعتماديات أو استدعاء ضخمة للمترجم/المربِّط. يجعل buildprof كل ذلك واضحًا جدًا، بحيث يمكنك رؤية ما يستحق التحقيق وتحسينه. تعمل من خلال وضع buildprof -- أمام أي أمر بناء تستخدمه بالفعل: buildprof -- make -j16، buildprof -- cargo build، buildprof -- ninja -C out/target، buildprof -- just build، buildprof -- ./dev/custom-build-script.sh. يسجل buildprof كل عملية يطلقها أمر البناء الخاص بك، بما في ذلك subprocesses (و subsubprocesses…)، ويوزعها على Timeline واحدة. يتحرك الوقت من اليسار إلى اليمين، وعرض الشريط يدل على المدة، وتظهر subprocessesbeneathwhatever launched them. بنيت buildprof لأن هذه التغريدة من Jarred Sumner، المهندس الرئيسي المعماري لـ Bun، كانت تعيش أجري بلا إيجار: وبالتحديد، الادعاء بأن Bun الجديدة Rust build كانت >5× أسرع في Linux من build Zig القديم. وفي خبرتي، كانت مشاريع Zig عادةً ما تُركب أسرع من مشاريع Rust ذات التعقيد المماثل. كانت هذه الحدس كافية لجعلني أشعر أن هناك لغزًا يجب حلَّه. وقد زاد من ذلك، تفصيل مهم ولكن سهل التغافل عنه في التغريدة: استخدم build Zig Full LTO، بينما استخدم build Rust Thin LTO. normally، يقوم المترجمون بتحسين وحداتCompile المنفصلة largely في عزلة. يسمح Link-time optimization (LTO) لهم بتحسين ما across تلك الحدود. يجمع Full LTO تلك الوحدات into optimization job واحد كبير، بينما يحافظ Thin LTO على مزيد من الفصل بحيث يمكن لمعظم العمل أن يعمل بالتوازي. بناءً على خبري السابق، يمكن أن يكون لهذه الاختلاف تأثير هائل على وقت البناء. وقد ذكرها التغريدة مرتَين، لكنني تساءلت كم من “العنوان” improvement كان يفسِّرها. بدأت بمحاولة إعادة إنتاج الأرقام. نجحت الأرقام في إعادة الإنتاج. ولكن ماذا بعد؟ قمت بتنزيل Bun 1.3.14 و Bun 1.4.0 وكتبتُ نصوصًا لإعادة تشغيل Builds Linux x64 CI الخاصة بها على VM Linux بستة نوى و 12 خيطًا. حفظت نصوص الخطوات وتعقيديات البناء، وأجرت كل شيء على آلة واحدة. كانت توقيتي في نفس النطاق مثل Jarred: Linux x64 build Zig era 30m06s، Rust era 5m37s. replay CI أحادي المachine 24m24s 5m40s. حسنًا، لذا ظهرت الفجوة أيضًا على جهاز الكمبيوتر الخاص بي. ولكن تغير الكثير بين القياسين بالإضافة إلى اللغة؛ فما هو المسؤول حقًا؟ هل كان مُركِّب Zig هو من يأخذ كل هذا الوقت الإضافي؟ أو ربما كان الربط Full LTO. أو ربما كان هناك شيء آخر في Build Bun لم أكن حتى قد فكرت به؟ هذه هي اللحظة التي دخل فيها عقلي التحليلي وأدوات المطور. عادةً، عندما أحاول فهم سبب بطء شيء ما، أريد Trace: ما الذي حدث، ومتى حدث، وكم استغرق من الوقت. سيكون من الرائع حقًا أن يكون لدينا هذا لهذه العمليات، لوضعها على Timeline ورؤية أين ذهبت وقتهم حقًا. ولكن تتضمن عملية البناء العديد من الأدوات المختلفة، لكل منها فكرتها الخاصة عما يحدث. ماذا يمكنني أن أسجل لأتمكن من رؤية عبر جميعها؟ عمليات البناء أشجار عمليات. عندما تقوم بتشغيل cargo build أو zig build، يبدو أنك تعمل برنامجًا واحدًا. يقوم نظام البناء بتحديد ما يحتاج إلى إعادة بناء، والترتيب بين تلك القطع وما يمكن أن يعمل بالتوازي. ولكن بشكل عام، لا يؤدي كل هذا العمل بنفسه؛ بل يطلق مُركِّبات، ومُنشئات Codes، ومربِّطين، وسكريبتاتArbitrary. هذه يمكنها إطلاق برامج أكثر التي launching بعضها أكثر... تصفِّب أنظمة البناء المختلفة هذا العمل بطرق مختلفة. Cargo يرى crates، وNinja يرى حواف البناء، وCMake يولِّد تعليمات لنظام بناء آخر. من التشغيل