M6 Mac mini vs GitHub का होस्टेड macOS रनर: एक Xcode बिल्ड बेंचमार्क

हम एक सवाल का असली आँकड़ा चाहते थे। किसी असली iOS ऐप पर डेडिकेटेड M6 Mac mini, GitHub के स्टैंडर्ड होस्टेड macOS रनर से कितना तेज़ है? तो हमने ओपन-सोर्स Wikipedia iOS ऐप दोनों पर बिल्ड किया। Xcode वही, स्क्रिप्ट वही, और हर मशीन पर तीन बार।

यह पोस्ट हमारी पिछली M4 बेंचमार्क पोस्ट की जगह लेती है। यहाँ का हर आँकड़ा 24 सितंबर 2026 को किए गए रन से है।

नतीजे

Median of 3 runs, in seconds. Lower is better.

                      GitHub-hosted   MacRun M6   change
                      macos-26
package download            43            39       -8%
clean build                183            86      -53%
incremental build           21            10      -51%
no-op build                 20            10      -50%
220 unit tests              44            17      -61%

कंपाइल करने में M6 लगभग दोगुना तेज़ रहा। पैकेज डाउनलोड में फ़र्क कम था, क्योंकि दोनों मशीनें तेज़ कनेक्शन पर GitHub से वही पैकेज खींचती हैं। हर रन में दोनों मशीनों पर हर स्टेप सफल रहा।

एक आम CI जॉब में कितना समय लगता है

टेबल मशीनों की तुलना स्टेप दर स्टेप करती है। असली CI जॉब दोनों पर अलग होता है। होस्टेड रनर हर जॉब ख़ाली शुरू करता है। उसे पैकेज डाउनलोड करने होते हैं, क्लीन बिल्ड करना होता है, फिर टेस्ट। डेडिकेटेड Mac अपना बिल्ड फ़ोल्डर रखता है। इसलिए छोटे बदलाव के बाद वह सिर्फ़ बदला हुआ हिस्सा दोबारा बनाता है।

यही वह फ़र्क है जो आपकी टीम महसूस करती है। जो जॉब साढ़े चार मिनट लेता था, वह तीस सेकंड से कम में पूरा होता है। ज़्यादा पुश वाले दिन बचे मिनट जुड़कर घंटे बन जाते हैं।

होस्टेड रनर पर इसी जॉब का पैसा भी लगता है। GitHub हर जॉब को पूरे मिनट तक राउंड करता है, इसलिए 269 सेकंड का बिल 5 मिनट का बनता है। $0.062 प्रति मिनट पर यह हर जॉब के लगभग 31 सेंट है। डेडिकेटेड Mac पर इसका कोई अतिरिक्त ख़र्च नहीं है। हमारा कॉस्ट कैलकुलेटर आपके जॉब की गिनती को मासिक आँकड़े में बदल देता है।

दोनों मशीनें

हार्डवेयर की जानकारी ख़ुद मशीनों से आई है। हर रन ने बिल्ड से पहले अपनी चिप, कोर की गिनती और मेमोरी प्रिंट की। GitHub ज़्यादा प्रति-मिनट कीमत पर बड़े macOS रनर भी बेचता है। हमने स्टैंडर्ड वाला टेस्ट किया, क्योंकि ज़्यादातर टीमें वही इस्तेमाल करती हैं।

मेथड

• प्रोजेक्ट: कमिट 8691a89 पर wikimedia/wikipedia-ios। इसे iOS Simulator के लिए इसकी Wikipedia स्कीम और Swift पैकेज के साथ बिल्ड किया गया।
• सिम्युलेटर: iOS 26.5 पर एक नया iPhone 17, दोनों मशीनों पर एक ही तरीके से बनाया गया।
• हर रन की शुरुआत में पैकेज कैश और DerivedData मिटा दिए गए। साइनिंग बंद थी, जैसा CI के सिम्युलेटर बिल्ड में आम तौर पर होता है।
• पैकेज डाउनलोड: एक ख़ाली फ़ोल्डर में xcodebuild -resolvePackageDependencies।
• क्लीन बिल्ड: ख़ाली DerivedData और पहले से डाउनलोड पैकेज के साथ xcodebuild build-for-testing।
• इंक्रीमेंटल बिल्ड: ऐप की एक Swift फ़ाइल में एक कमेंट लाइन जोड़ने के बाद वही कमांड।
• नो-ऑप बिल्ड: बिना किसी बदलाव के वही कमांड फिर से।
• टेस्ट: ऐप के WMFData पैकेज के 220 यूनिट टेस्ट, एक बूट किए हुए सिम्युलेटर पर test-without-building से चलाए गए।
• हर मशीन पर तीन पूरे रन। हम मीडियन बताते हैं।

ध्यान देने वाली बातें

हमने ऐप के पैकेज टेस्ट चलाए, उसका मुख्य टेस्ट टारगेट नहीं। मुख्य टारगेट को साइन किए हुए app-group entitlements चाहिए, और बिना साइन वाले CI बिल्ड में ये नहीं होते। उसका टेस्ट होस्ट दोनों मशीनों पर बार-बार दोबारा लॉन्च होता रहा। इसलिए वह सही माप नहीं था।

इंक्रीमेंटल बिल्ड ने एक छोटी फ़ाइल बदली। उसके 10 सेकंड में से ज़्यादातर समय Xcode बिल्ड की योजना बनाने में लगाता है। इसीलिए यह नो-ऑप बिल्ड के बराबर है। किसी ज़्यादा इस्तेमाल होने वाली फ़ाइल में बदलाव दोनों मशीनों पर ज़्यादा समय लेगा।

दोनों मशीनों पर macOS के अलग वर्ज़न थे, क्योंकि हर एक पर वही चला जो उसका मालिक आज देता है। होस्टेड जॉब actions/cache से Swift पैकेज कैश भी कर सकता है। इससे डाउनलोड स्टेप घटेगा। पर क्लीन बिल्ड नहीं हटेगा, और ज़्यादातर समय वही लेता है।

हम M6 रनर बेचते हैं, इसलिए हमारे आँकड़ों को यह ध्यान में रखकर तौलें। ऊपर का मेथड इतना पूरा है कि आप इसे अपने प्रोजेक्ट पर दोबारा चला सकें। आपके लिए असल मायने वाला बेंचमार्क वही है।