रुबी परियोजना के साथ उतरने के बाद, मैं प्रदर्शन के कारण रुबी का उपयोग करने के फैसले के बारे में संदेह कर रहा हूं।
मैं अपने जावा एकीकरण के साथ जेआरबीई खोजने के लिए उत्साहित था। इसने परियोजना को मेरे लिए व्यापक रूप से आसान बना दिया है। और अब मैं यह पता लगाने के लिए अभी भी पूरी तरह से उलझा हुआ हूं कि जेआरबीई हो सकता है जावा बाइटकोड में संकलित .
बेंचमार्क आंकड़ों के साथ ऐसा:
फाइब (30) रूबी: 1.67 एस
फाइब (30) जेआरबी इंटरप (क्लाइंट वीएम): 3.93 एस
फाइब (30) जेआरबी इंटरप (सर्वर वीएम): 2.28 से 2.08 एस
फाइब (30) जेआरबी संकलित (क्लाइंट वीएम): 1.89 से 1.79 एस
फाइब (30) जेआरबी संकलित (सर्वर वीएम): 1.66 से 0.86 एस
अब मैं यहां जेआरबी की अपनी पसंद के बारे में बहुत उत्साहित हूं। क्या कोई नुकसान या कारण है कि आप उत्पादन रिलीज के लिए संकलित क्यों नहीं करेंगे?
उत्तर:
उत्तर № 1 के लिए 1वितरण और प्रतिष्ठान करेंगेयह निर्णय मेरे लिए आसान है: एक sysadmin के रूप में, मैं सिर्फ एक। जेएआर फ़ाइल वितरित करता हूं जो कई जेआरई पर चल रहा है, जो एक काम कर रहे जेआरबीई उदाहरण (जो कि विभिन्न ओएस के लिए अलग है) को वितरित करने के बजाय तथा मेरा स्रोत कोड इसके अलावा, आप पहले से ही दिखा चुके हैं कि एओटी-संकलित कोड व्याख्या / जेआईटी से तेज है, इसलिए संकलित संस्करण वितरित करने के सभी और कारण हैं।
जवाब के लिए 0 № 2
रूबी विकसित करने के लिए बहुत तेज़ है (यदि आप इसकी शैली से परिचित हैं)।
यह दौड़ने के लिए इतना तेज़ नहीं है, लेकिन यह आमतौर पर एक बड़ा ऋण नहीं है। अधिकांश वर्कलोड, यहां तक कि बड़ी वेबसाइटों के लिए यह काफी तेज़ है।
निर्णय रनटाइम गति पर आधारित नहीं होना चाहिए - जब तक आपके पास आंकड़े न कहें कि लोगों को प्रदर्शन से नाखुश होने की उम्मीद है - बल्कि तैनाती में आसानी।
यदि आपके पूर्ववर्तियों द्वारा रूबी अनुप्रयोगों की तैनाती हासिल की गई है, तो इसे रूबी रखें।
यदि JVM पर तैनाती आसान है, तो उसके साथ जाएं।