أسباب عدم التجميع

Question

بعد أن هبطت مع مشروع روبي ، كنت متشككًا في قرار استخدام روبي بسبب الأداء.

كنت متحمسًا لاكتشاف Jruby مع تكامل Java. وقد جعل هذا المشروع أسهل بشكل كبير بالنسبة لي. والآن لقد شعرت بدغ دغدغة أكثر من ذلك لاكتشاف أن Jruby يمكن أن يكون تم تجميعها إلى Java Bytecode .

مع شخصيات مرجعية مثل ذلك:

FIB (30) روبي: 1.67s

FIB (30) Jruby Interp (Client VM): 3.93S

FIB (30) JRUBY Interp (Server VM): 2.28s to 2.08s

FIB (30) JRUBY المترجمة (العميل VM): 1.89S إلى 1.79S

FIB (30) JRUBY المترجمة (Server VM): 1.66s إلى 0.86s

أنا الآن متحمس للغاية لاختيارنا من jruby هنا. هل هناك أي عيوب أو أسباب تجعلك لا تجمع إصدار الإنتاج؟

Answer 1

من شأن التوزيع والتركيبات أن يجعل هذا القرار أسهل بالنسبة لي: بصفتي sysadmin ، أفضل توزيع ملف .jar فقط يمكن أن يعمل على العديد من JRE بدلاً من توزيع مثيل JRUBY العام مثال) و رمز المصدر الخاص بي. بالإضافة إلى ذلك ، لقد أثبتت بالفعل أن التعليمات البرمجية المبللة AOT أسرع من التفسير/JIT ، لذلك كل ما هو أكثر سببًا لتوزيع الإصدار المترجم.

Answer 2

روبي سريع للغاية لتطوره (إذا كنت على دراية بأسلوبه).

ليس من السريع الركض ، ولكن هذا ليس عادة ناقصًا كبيرًا. إنها سريعة بما يكفي لمعظم أعباء العمل ، وحتى مواقع الويب الكبيرة.

لا ينبغي أن يستند القرار إلى سرعة وقت التشغيل - إلا إذا كان لديك إحصائيات للقول إن الأشخاص يتوقعون أن يكونوا غير راضين عن الأداء - بل سهولة النشر.

إذا تم تحقيق نشر تطبيقات Ruby من قبل أسلافك ، فاحرص عليه Ruby.

إذا كان الانتشار إلى JVM أسهل ، فانتقل إلى ذلك.