أداء جافا

📅 آخر تحديث: ١ أغسطس ٢٠٢٦
✍️ نُشر في: ١ أغسطس ٢٠٢٦
الموسوعة الحرة

في مجال تطوير البرمجيات ، كانت لغة البرمجة جافا تُعتبر تاريخيًا أبطأ من أسرع لغات الجيل الثالث ذات الكتابة ، مثل C و C++ . [ 1 ] على عكس تلك اللغات، تُترجم جافا افتراضيًا إلى آلة جافا الافتراضية (JVM) بعمليات منفصلة عن عمليات عتاد الحاسوب الفعلي. كانت تطبيقات JVM الأولى عبارة عن مترجمات ؛ حيث كانت تحاكي العمليات الافتراضية واحدة تلو الأخرى بدلًا من ترجمتها إلى رمز الآلة للتنفيذ المباشر على العتاد.

منذ أواخر التسعينيات، تحسّنت سرعة تنفيذ برامج جافا بشكل ملحوظ بفضل إدخال الترجمة الفورية (JIT) (في عام ١٩٩٧ لجافا ١.١ )، [ ٢ ] [ ٣ ] [ ٤ ] وإضافة ميزات لغوية تدعم تحليلًا أفضل للتعليمات البرمجية، وتحسينات في آلة جافا الافتراضية (مثل اعتماد HotSpot كخيار افتراضي لآلة جافا الافتراضية من صن في عام ٢٠٠٠). كما شهدت استراتيجيات جمع البيانات المهملة المتطورة تحسينات ملحوظة. وتم استكشاف إمكانية تنفيذ بايت كود جافا على مستوى الأجهزة، كما هو الحال في معالج Jazelle من ARM ، ولكن لم يتم تطبيقها.

يعتمد أداء برنامج جافا المُترجم إلى بايت كود على مدى كفاءة إدارة مهامه بواسطة آلة جافا الافتراضية (JVM)، وعلى مدى استغلالها لميزات عتاد الحاسوب ونظام التشغيل . لذا، يجب أن يتضمن أي اختبار أو مقارنة لأداء جافا ذكر إصدار، واسم الشركة المصنعة، ونظام التشغيل، وبنية عتاد آلة جافا الافتراضية المستخدمة. وبالمثل، يعتمد أداء البرنامج المُترجم أصلاً على جودة كود الآلة المُولّد، لذا يجب أن يتضمن الاختبار أو المقارنة أيضًا اسم، وإصدار، واسم الشركة المصنعة للمُترجم المستخدم، وتوجيهات تحسين المُترجم المُفعّلة .

أساليب تحسين الآلة الافتراضية

ساهمت العديد من التحسينات في رفع أداء آلة جافا الافتراضية (JVM) بمرور الوقت. ومع ذلك، ورغم أن جافا كانت في كثير من الأحيان أول آلة افتراضية تُطبّق هذه التحسينات بنجاح، فقد استُخدمت هذه التحسينات أيضاً في منصات أخرى مماثلة.

التجميع في الوقت المناسب

كانت آلات جافا الافتراضية المبكرة تُفسّر دائمًا بايت كود جافا . وقد تسبب ذلك في انخفاض كبير في الأداء يتراوح بين 10 و20 ضعفًا لجافا مقارنةً بلغة C في التطبيقات المتوسطة. [ 5 ] ولمعالجة هذه المشكلة، تم تقديم مُصرّف فوري (JIT) في جافا 1.1. ونظرًا للتكلفة العالية للترجمة، تم تقديم نظام إضافي يُسمى HotSpot في جافا 1.2، وأصبح النظام الافتراضي في جافا 1.3. باستخدام هذا الإطار، تُحلل آلة جافا الافتراضية أداء البرنامج باستمرار بحثًا عن النقاط الساخنة التي يتم تنفيذها بشكل متكرر. ثم يتم استهداف هذه النقاط لتحسينها ، مما يؤدي إلى تنفيذ عالي الأداء مع الحد الأدنى من الحمل الزائد للتعليمات البرمجية الأقل حساسية للأداء. [ 6 ] [ 7 ] تُظهر بعض الاختبارات المعيارية زيادة في السرعة بمقدار 10 أضعاف بهذه الطريقة. [ 8 ] ومع ذلك، ونظرًا لضيق الوقت، لا يستطيع المُصرّف تحسين البرنامج بشكل كامل، وبالتالي يكون البرنامج الناتج أبطأ من بدائل التعليمات البرمجية الأصلية. [ 9 ] [ 10 ]

التحسين التكيفي

التحسين التكيفي هو أسلوب في علوم الحاسوب يُجري إعادة ترجمة ديناميكية لأجزاء من البرنامج بناءً على ملف تعريف التنفيذ الحالي. في أبسط تطبيقاته، قد يُوازن المُحسِّن التكيفي بين الترجمة الفورية وتفسير التعليمات. وعلى مستوى آخر، قد يستغل التحسين التكيفي ظروف البيانات المحلية لتحسين التفرعات واستخدام التوسيع المضمن.

يمكن لآلة جافا الافتراضية مثل HotSpot أيضًا إلغاء تحسين الكود الذي كان يُترجم في الوقت الفعلي (JIT). يتيح ذلك إجراء تحسينات مكثفة (وربما غير آمنة)، مع إمكانية إلغاء تحسين الكود لاحقًا والعودة إلى مسار آمن. [ 11 ] [ 12 ]

جمع القمامة

استخدمت آلات جافا الافتراضية (JVMs) الإصدارين 1.0 و1.1 مُجمِّعًا من نوع "mark-sweep" ، والذي كان يُجزِّئ الذاكرة بعد عملية جمع البيانات المهملة. بدءًا من جافا 1.2، تحوّلت آلات جافا الافتراضية إلى مُجمِّع من نوع "generalal collector" ، والذي يتميز بسلوك أفضل بكثير في إلغاء التجزئة. [ 13 ] تستخدم آلات جافا الافتراضية الحديثة مجموعة متنوعة من الأساليب التي حسّنت أداء جمع البيانات المهملة بشكل أكبر . [ 14 ]

طرق التحسين الأخرى

أخطاء مضغوطة

تتيح ميزة ضغط الكائنات في Java 5.0 والإصدارات الأحدث الوصول إلى مساحة تصل إلى 32 جيجابايت من الذاكرة الديناميكية (heap) باستخدام مراجع 32 بت. لا تدعم Java الوصول إلى البايتات الفردية، بل فقط إلى الكائنات التي تتم محاذاتها افتراضيًا إلى 8 بايت. ولهذا السبب، تكون البتات الثلاثة الأدنى في مرجع الذاكرة الديناميكية دائمًا أصفارًا. من خلال خفض دقة المراجع 32 بت إلى كتل 8 بايت، يمكن زيادة مساحة العنونة إلى 32 جيجابايت. هذا يقلل بشكل كبير من استخدام الذاكرة مقارنةً باستخدام مراجع 64 بت، حيث تستخدم Java المراجع بشكل أكبر بكثير من بعض اللغات مثل C++. يدعم Java 8 محاذاة أكبر، مثل محاذاة 16 بايت، لدعم مساحة تصل إلى 64 جيجابايت باستخدام مراجع 32 بت.

التحقق من تقسيم رمز البايت

قبل تنفيذ أي فئة ، يتحقق نظام التشغيل Java VM من Sun من صحة بايت كود Java الخاص بها (انظر أداة التحقق من البايت كود ). يتم هذا التحقق بشكل كسول: حيث لا يتم تحميل بايت كود الفئات والتحقق منه إلا عند تحميل الفئة المحددة وتجهيزها للاستخدام، وليس في بداية البرنامج. مع ذلك، ولأن مكتبات فئات Java هي أيضًا فئات Java عادية، يجب تحميلها عند استخدامها، مما يعني أن وقت بدء تشغيل برنامج Java غالبًا ما يكون أطول من برامج C++ ، على سبيل المثال.

تُستخدم طريقة تسمى التحقق من الوقت المنقسم ، والتي تم تقديمها لأول مرة في منصة جافا، الإصدار المصغر (J2ME)، في JVM منذ إصدار جافا 6. وهي تقسم عملية التحقق من بايت كود جافا إلى مرحلتين: [ 15 ]

  • وقت التصميم - عند تجميع فئة من المصدر إلى رمز البايت
  • وقت التشغيل – عند تحميل فئة.

تعتمد هذه الطريقة عمليًا على استخلاص المعلومات التي يمتلكها مُصرّف جافا حول تدفق الفئات، وإضافة تعليقات توضيحية إلى التعليمات البرمجية المُصرّفة للأساليب، تتضمن ملخصًا لمعلومات تدفق الفئات. لا يُقلل هذا من تعقيد عملية التحقق أثناء التشغيل بشكل ملحوظ، ولكنه يُتيح بعض الاختصارات.

تحليل الهروب وتخشين القفل

تستطيع لغة جافا إدارة تعدد الخيوط على مستوى اللغة. يسمح تعدد الخيوط للبرامج بتنفيذ عمليات متعددة في وقت واحد، مما يُحسّن أداء البرامج التي تعمل على أنظمة حاسوبية متعددة المعالجات أو النوى. كما يمكن للتطبيق متعدد الخيوط أن يظل متجاوبًا مع المدخلات، حتى أثناء تنفيذ مهام طويلة الأمد.

مع ذلك، تحتاج البرامج التي تستخدم تعدد الخيوط إلى توخي الحذر الشديد بشأن الكائنات المشتركة بين الخيوط، وذلك بتأمين الوصول إلى الطرق أو الكتل المشتركة عند استخدامها من قِبل أحد الخيوط. يُعد تأمين كتلة أو كائن عمليةً تستغرق وقتًا طويلاً نظرًا لطبيعة العملية الأساسية على مستوى نظام التشغيل (انظر التحكم بالتزامن ودقة التأمين ).

بما أن مكتبة جافا لا تعرف الطرق التي سيتم استخدامها بواسطة أكثر من خيط واحد، فإن المكتبة القياسية تقوم دائمًا بقفل الكتل عند الحاجة في بيئة متعددة الخيوط.

قبل إصدار Java 6، كانت الآلة الافتراضية تقوم دائمًا بقفل الكائنات والكتل البرمجية عند طلب البرنامج ذلك، حتى لو لم يكن هناك خطر من تعديل كائن ما بواسطة خيطين مختلفين في آن واحد. على سبيل المثال، في هذه الحالة، Vectorتم قفل متغير محلي قبل كل عملية جمع لضمان عدم تعديله بواسطة خيوط أخرى ( Vectorلأن العملية متزامنة)، ولكن نظرًا لأنه محلي تمامًا للدالة، فإن هذا القفل غير ضروري.

public String getNames () { final Vector < String > v = new Vector <> (); v . add ( "Me" ); v . add ( "You" ); v . add ( "Her" ); return v . toString (); }

بدءًا من Java 6، يتم قفل كتل التعليمات البرمجية والكائنات فقط عند الحاجة، [ 16 ] لذلك في الحالة المذكورة أعلاه، لن تقوم الآلة الافتراضية بقفل كائن Vector على الإطلاق.

منذ الإصدار 6u23، تتضمن لغة جافا دعمًا لتحليل الهروب. [ 17 ]

تحسينات في تخصيص السجلات

قبل إصدار Java 6 ، كان تخصيص السجلات في الآلة الافتراضية للعميل بدائيًا للغاية (لم تكن السجلات موزعة على كتل )، مما شكّل مشكلة في تصميمات المعالجات التي تحتوي على عدد أقل من سجلات المعالج المتاحة، كما هو الحال في معالجات x86 . إذا لم تكن هناك سجلات متاحة لإجراء عملية ما، يجب على المُصرّف نسخ البيانات من السجل إلى الذاكرة (أو من الذاكرة إلى السجل)، وهو ما يستغرق وقتًا (الوصول إلى السجلات أسرع بكثير). مع ذلك، استخدمت الآلة الافتراضية للخادم مُخصِّصًا يعتمد على الرسم البياني اللوني، ولم تكن تعاني من هذه المشكلة.

أُدخل تحسين على تخصيص السجلات في JDK 6 من Sun؛ [ 18 ] وأصبح من الممكن حينها استخدام السجلات نفسها عبر الكتل (عند الاقتضاء)، مما قلل من عمليات الوصول إلى الذاكرة. وقد أدى ذلك إلى زيادة في الأداء بلغت حوالي 60% في بعض الاختبارات المعيارية. [ 19 ]

مشاركة بيانات الفئة

تُعدّ مشاركة بيانات الفئات (المعروفة باسم CDS من قِبل شركة Sun) آليةً تُقلّل من وقت بدء تشغيل تطبيقات Java، وتُقلّل أيضًا من استهلاك الذاكرة . عند تثبيت بيئة تشغيل Java (JRE) ، يقوم المُثبِّت بتحميل مجموعة من الفئات من ملف JAR الخاص بالنظام (ملف JAR الذي يحتوي على مكتبة فئات Java بأكملها، ويُسمى rt.jar) إلى تمثيل داخلي خاص، ثم يُخزّن هذا التمثيل في ملف يُسمى "أرشيفًا مشتركًا". خلال عمليات استدعاء JVM اللاحقة، يتم ربط هذا الأرشيف المشترك بالذاكرة ، مما يُوفّر تكلفة تحميل تلك الفئات ويسمح بمشاركة جزء كبير من بيانات JVM الوصفية لهذه الفئات بين عمليات JVM المتعددة. [ 20 ]

ويكون التحسن المقابل في وقت بدء التشغيل أكثر وضوحًا بالنسبة للبرامج الصغيرة. [ 21 ]

تاريخ تحسينات الأداء

بصرف النظر عن التحسينات المذكورة هنا، فقد قدم كل إصدار من Java العديد من التحسينات في الأداء في JVM وواجهة برمجة تطبيقات Java (API).

JDK 1.1.6: أول عملية تجميع في الوقت المناسب ( مترجم JIT من Symantec ) [ 2 ] [ 22 ]

J2SE 1.2: استخدام جامع الأجيال .

J2SE 1.3: التجميع الفوري بواسطة HotSpot .

J2SE 1.4: انظر هنا ، للحصول على نظرة عامة من Sun حول تحسينات الأداء بين الإصدارين 1.3 و 1.4.

Java SE 5.0: مشاركة بيانات الفئة [ 23 ]

جافا إس إي 6:

تحسينات أخرى:

انظر أيضًا "نظرة عامة من صن على تحسينات الأداء بين جافا 5 وجافا 6". [ 26 ]

Java SE 6 Update 10

  • يعمل برنامج Java Quick Starter على تقليل وقت بدء تشغيل التطبيق عن طريق التحميل المسبق لجزء من بيانات JRE عند بدء تشغيل نظام التشغيل على ذاكرة التخزين المؤقت للقرص . [ 27 ]
  • يتم الآن تنزيل أجزاء النظام الأساسية اللازمة لتشغيل تطبيق يتم الوصول إليه من الويب في حال عدم تثبيت بيئة تشغيل جافا (JRE) أولاً. يبلغ حجم بيئة تشغيل جافا الكاملة 12 ميجابايت، بينما يحتاج تطبيق Swing النموذجي إلى تنزيل 4 ميجابايت فقط لبدء التشغيل. ثم يتم تنزيل الأجزاء المتبقية في الخلفية. [ 28 ]
  • تم تحسين أداء الرسومات على نظام التشغيل ويندوز من خلال الاستخدام المكثف لـ Direct3D بشكل افتراضي، [ 29 ] واستخدام التظليل على وحدة معالجة الرسومات (GPU) لتسريع عمليات Java 2D المعقدة . [ 30 ]

جافا 7

تم إصدار العديد من التحسينات على الأداء لـ Java 7: ومن المخطط إجراء تحسينات مستقبلية على الأداء لتحديث Java 6 أو Java 7: [ 31 ]

  • توفير دعم JVM للغات البرمجة الديناميكية ، وذلك بعد أعمال النماذج الأولية التي يتم إجراؤها حاليًا على آلة دافنشي (آلة افتراضية متعددة اللغات)، [ 32 ]
  • تحسين مكتبة التزامن الحالية من خلال إدارة الحوسبة المتوازية على المعالجات متعددة النوى ، [ 33 ] [ 34 ]
  • السماح لـ JVM باستخدام كل من مترجمات JIT الخاصة بالعميل والخادم في نفس الجلسة باستخدام طريقة تسمى التجميع المتدرج: [ 35 ]
    • سيتم استخدام العميل عند بدء التشغيل (لأنه جيد عند بدء التشغيل وللتطبيقات الصغيرة)،
    • سيتم استخدام الخادم لتشغيل التطبيق على المدى الطويل (لأنه يتفوق على مترجم العميل في هذا الصدد).
  • استبدل جامع البيانات المهملة المتزامن ذو فترات التوقف القصيرة الحالي (المعروف أيضًا باسم جامع البيانات المهملة المتزامن ذو علامات المسح (CMS)) بجامع بيانات مهملة جديد يُسمى "البيانات المهملة أولاً" (G1) لضمان فترات توقف متسقة مع مرور الوقت. [ 36 ] [ 37 ]

مقارنة باللغات الأخرى

يتطلب إجراء مقارنة موضوعية لأداء برنامج مكتوب بلغة جافا مع برنامج مماثل مكتوب بلغة أخرى مثل C ++ معيارًا معياريًا مصممًا بعناية فائقة لمقارنة البرامج التي تؤدي مهامًا متطابقة. تستهدف منصة جافا نفسها منصة جافا ، حيث يتم تفسير أو ترجمة الشفرة البايتية إلى شفرة آلية بواسطة آلة جافا الافتراضية (JVM). أما المترجمات الأخرى، فتستهدف عادةً منصة برمجية أو عتادية محددة، وتنتج شفرة آلية تبقى ثابتة تقريبًا أثناء التنفيذ . ينتج عن هذين النهجين المختلفين سيناريوهات شديدة التباين ويصعب مقارنتها: الترجمة الثابتة مقابل الترجمة الديناميكية وإعادة الترجمة ، وتوفر معلومات دقيقة حول بيئة التشغيل، وغيرها.

غالبًا ما يتم تجميع لغة جافا في وقت التشغيل بواسطة آلة جافا الافتراضية ، ولكن يمكن أيضًا تجميعها مسبقًا ، كما هو الحال مع لغة C++. عند تجميعها في وقت التشغيل، تشير المعايير الدقيقة للعبة معايير لغات البرمجة إلى ما يلي حول أدائها: [ 38 ]

  • أبطأ من اللغات المترجمة مثل C أو C++ ، [ 39 ]
  • على غرار لغات الترجمة الفورية الأخرى مثل C# ، [ 40 ]
  • أسرع بكثير من اللغات التي لا تحتوي على مترجم كود أصلي فعال ( JIT أو AOT )، مثل Perl و Ruby و PHP و Python . [ 41 ]

برامج

غالبًا ما تقيس الاختبارات المعيارية أداء البرامج الصغيرة ذات العمليات الحسابية المكثفة. في بعض البرامج الواقعية النادرة، يتفوق جافا على لغة سي. ومن الأمثلة على ذلك اختبار Jake2 (نسخة من لعبة Quake II مكتوبة بلغة جافا عن طريق ترجمة كود C الأصلي المرخص بموجب رخصة GPL ). يُظهر إصدار جافا 5.0 أداءً أفضل في بعض تكوينات الأجهزة مقارنةً بنظيره المكتوب بلغة سي. [ 42 ] على الرغم من عدم تحديد كيفية قياس البيانات (على سبيل المثال، ما إذا تم استخدام ملف Quake II التنفيذي الأصلي الذي تم تجميعه عام 1997، وهو ما قد يُعتبر غير مناسب نظرًا لأن مُجمِّعات لغة سي الحالية قد تُحقق تحسينات أفضل للعبة Quake)، إلا أنه يُشير إلى كيف يُمكن لنفس كود جافا المصدري أن يحقق قفزة هائلة في السرعة بمجرد تحديث الآلة الافتراضية، وهو أمر مستحيل تحقيقه باتباع نهج ثابت بنسبة 100%.

بالنسبة لبرامج أخرى، يمكن لنسخة C++ أن تعمل، بل وعادةً ما تعمل، أسرع بكثير من نسخة Java. أظهر اختبار معياري أجرته جوجل عام 2011 فرقًا قدره 10 أضعاف بين C++ وJava. [ 43 ] في المقابل، أظهر اختبار معياري أكاديمي أُجري عام 2012 باستخدام خوارزمية نمذجة ثلاثية الأبعاد أن Java 6 JVM أبطأ من C++ بمقدار 1.09 إلى 1.91 مرة على نظام Windows. [ 44 ]

قد لا تكون بعض التحسينات الممكنة في لغة جافا واللغات المشابهة ممكنة في ظروف معينة في لغة C++: [ 45 ]

  • قد يعيق استخدام المؤشرات على نمط لغة C عملية التحسين في اللغات التي تدعم المؤشرات.
  • يُعد استخدام أساليب تحليل الهروب محدودًا في لغة C++ ، على سبيل المثال، لأن مترجم C++ لا يعرف دائمًا ما إذا كان سيتم تعديل كائن ما في كتلة معينة من التعليمات البرمجية بسبب المؤشرات ، [ ملاحظة 1 ]
  • تستطيع لغة جافا الوصول إلى توابع النسخ المشتقة أسرع من لغة سي++ في الوصول إلى التوابع الافتراضية المشتقة، وذلك بفضل استخدام سي++ لجدول التوابع الافتراضية. مع ذلك، لا تعاني التوابع غير الافتراضية في سي++ من اختناقات الأداء الناتجة عن جدول التوابع الافتراضية، وبالتالي يكون أداؤها مماثلاً لأداء جافا.

تستطيع آلة جافا الافتراضية (JVM) أيضًا إجراء تحسينات خاصة بالمعالج أو توسيع مضمن . كما أن قدرتها على إلغاء تحسين التعليمات البرمجية التي تم تجميعها أو تضمينها مسبقًا تسمح لها أحيانًا بإجراء تحسينات أكثر فعالية من تلك التي تُجريها اللغات ذات الكتابة الثابتة عند استخدام وظائف مكتبات خارجية. [ 46 ] [ 47 ]

تعتمد نتائج الاختبارات المعيارية الدقيقة بين Java و C++ بشكل كبير على العمليات التي تتم مقارنتها. على سبيل المثال، عند المقارنة مع Java 5.0:

ملحوظات
  1. ↑ يمكن تخفيف هذا النوع من التنازع في برامج C++ على مستوى الكود المصدري من خلال استخدام أساليب متقدمة مثل المخصصات المخصصة ، واستغلال نوع تعقيد البرمجة منخفض المستوى الذي صُممت Java لإخفائه وتغليفه؛ ومع ذلك، نادرًا ما يكون هذا النهج عمليًا إذا لم يتم اعتماده (أو على الأقل توقعه) أثناء بقاء البرنامج قيد التطوير الأساسي.

أداء متعدد النوى

تتأثر قابلية التوسع وأداء تطبيقات جافا على الأنظمة متعددة النوى بمعدل تخصيص الكائنات. ويُطلق على هذه الظاهرة أحيانًا اسم "حاجز التخصيص". [ 54 ] مع ذلك، تستخدم خوارزميات جمع البيانات المهملة الحديثة عمليًا نوى متعددة لإجراء عملية جمع البيانات المهملة، مما يُخفف من هذه المشكلة إلى حد ما. وقد أشارت بعض التقارير إلى أن بعض خوارزميات جمع البيانات المهملة تحافظ على معدلات تخصيص تتجاوز غيغابايت واحد في الثانية، [ 55 ] كما توجد أنظمة مبنية على جافا لا تواجه أي مشكلة في التوسع لتشمل مئات من نوى وحدة المعالجة المركزية وأكوامًا بحجم مئات الغيغابايت. [ 56 ]

تتيح إدارة الذاكرة التلقائية في جافا استخدامًا فعالًا لهياكل البيانات غير القابلة للقفل وغير القابلة للتغيير، والتي يصعب أو يستحيل أحيانًا تنفيذها دون استخدام آلية لجمع البيانات المهملة. توفر جافا عددًا من هذه الهياكل عالية المستوى في مكتبتها القياسية ضمن حزمة java.util.concurrent، بينما لا تزال العديد من اللغات التي استُخدمت تاريخيًا لأنظمة الأداء العالي، مثل C أو C++، تفتقر إليها.

وقت بدء التشغيل

غالبًا ما يكون وقت بدء تشغيل Java أبطأ بكثير من العديد من اللغات، بما في ذلك C و C++ و Perl أو Python ، لأنه يجب تحميل العديد من الفئات (وأولاً وقبل كل شيء الفئات من مكتبات فئات النظام الأساسي ) قبل استخدامها.

عند مقارنتها بأوقات التشغيل الشائعة المماثلة، بالنسبة للبرامج الصغيرة التي تعمل على جهاز يعمل بنظام التشغيل Windows، يبدو أن وقت بدء التشغيل مشابه لوقت بدء تشغيل Mono وأبطأ قليلاً من وقت بدء تشغيل .NET . [ 57 ]

يبدو أن جزءًا كبيرًا من وقت بدء التشغيل يعود إلى عمليات الإدخال والإخراج، وليس إلى تهيئة JVM أو تحميل الفئات ( يبلغ حجم ملف بيانات فئة rt.jar وحده 40 ميجابايت، ويتعين على JVM البحث عن كمية كبيرة من البيانات في هذا الملف الضخم). [ 27 ] أظهرت بعض الاختبارات أنه على الرغم من أن طريقة التحقق الجديدة من تقسيم رمز البايت قد حسّنت تحميل الفئات بنسبة 40% تقريبًا، إلا أنها لم تُحقق سوى تحسينًا بنسبة 5% تقريبًا في بدء تشغيل البرامج الكبيرة. [ 58 ]

على الرغم من أنه تحسن طفيف، إلا أنه أكثر وضوحًا في البرامج الصغيرة التي تقوم بعملية بسيطة ثم تخرج، لأن تحميل بيانات منصة جافا يمكن أن يمثل أضعاف حمل عملية البرنامج الفعلية.

ابتداءً من Java SE 6 Update 10، يأتي Sun JRE مزودًا ببرنامج Quick Starter الذي يقوم بتحميل بيانات الفئة مسبقًا عند بدء تشغيل نظام التشغيل للحصول على البيانات من ذاكرة التخزين المؤقت للقرص بدلاً من القرص.

يعالج Excelsior JET المشكلة من جانب آخر. يعمل مُحسِّن بدء التشغيل الخاص به على تقليل كمية البيانات التي يجب قراءتها من القرص عند بدء تشغيل التطبيق، ويجعل عمليات القراءة أكثر تسلسلاً.

في نوفمبر 2004، تم إطلاق Nailgun ، وهو عبارة عن "عميل وبروتوكول وخادم لتشغيل برامج جافا من سطر الأوامر دون تكبد عبء بدء تشغيل JVM". [ 59 ] وقد قدم لأول مرة خيارًا للبرامج النصية لاستخدام JVM كخدمة خلفية ، لتشغيل تطبيق جافا واحد أو أكثر دون أي عبء بدء تشغيل JVM. إلا أن خدمة Nailgun الخلفية غير آمنة: "يتم تشغيل جميع البرامج بنفس صلاحيات الخادم". لذا، في حال الحاجة إلى أمان متعدد المستخدمين ، فإن Nailgun غير مناسب دون اتخاذ احتياطات خاصة. أما البرامج النصية التي يهيمن فيها بدء تشغيل JVM لكل تطبيق على استخدام الموارد، فتشهد تحسينات في أداء وقت التشغيل تتراوح بين عشرة أضعاف ومئة ضعف . [ 60 ]

استخدام الذاكرة

يُعد استخدام الذاكرة في لغة جافا أعلى بكثير من استخدامها في لغة سي++ للأسباب التالية:

  • في لغة جافا، يُضاف حجم 8 بايتات لكل كائن و12 بايتًا لكل مصفوفة [ 61 ] . إذا لم يكن حجم الكائن من مضاعفات 8 بايتات، يُقرّب إلى أقرب مضاعف للعدد 8. هذا يعني أن الكائن الذي يحتوي على حقل بايت واحد يشغل 16 بايتًا ويحتاج إلى مرجع بحجم 4 بايتات. كما تُخصّص لغة C++ مؤشرًا ( عادةً 4 أو 8 بايتات) لكل كائن تُصرّح فئته، بشكل مباشر أو غير مباشر، عن دوال افتراضية [ 62 ] .
  • إن عدم وجود حساب العناوين يجعل إنشاء حاويات فعالة من حيث الذاكرة، مثل الهياكل المتباعدة بإحكام وقوائم XOR المرتبطة ، أمرًا مستحيلاً حاليًا ( يهدف مشروع OpenJDK Valhalla إلى التخفيف من هذه المشكلات، على الرغم من أنه لا يهدف إلى إدخال حساب المؤشرات؛ لا يمكن القيام بذلك في بيئة جمع القمامة).
  • على عكس malloc و new، فإن متوسط ​​الحمل الزائد على الأداء الناتج عن جمع البيانات المهملة يقترب بشكل مقارب من الصفر (أو بدقة أكبر، دورة معالجة واحدة) مع زيادة حجم الكومة. [ 63 ]
  • يجب تحميل أجزاء من مكتبة فئات جافا قبل تنفيذ البرنامج (على الأقل الفئات المستخدمة داخل البرنامج). [ 64 ] يؤدي هذا إلى زيادة كبيرة في استهلاك الذاكرة للتطبيقات الصغيرة.
  • عادةً ما يكون كل من ملف Java الثنائي وإعادة التجميع الأصلية موجودين في الذاكرة.
  • تستخدم الآلة الافتراضية ذاكرة كبيرة.
  • في لغة جافا، يتم إنشاء كائن مركب (فئة A تستخدم مثيلات من B و C) باستخدام مراجع إلى مثيلات مخصصة من B و C. في لغة C++، يمكن تجنب تكلفة الذاكرة والأداء لهذه الأنواع من المراجع عندما يكون مثيل B و/أو C موجودًا داخل A.

في معظم الحالات، يستهلك تطبيق C++ ذاكرة أقل من تطبيق Java مكافئ له، وذلك بسبب العبء الكبير الذي يفرضه نظام Java الافتراضي، وتحميل الفئات، وتغيير حجم الذاكرة تلقائيًا. أما بالنسبة للبرامج التي تُعد فيها الذاكرة عاملًا حاسمًا في اختيار لغة البرمجة أو بيئة التشغيل، فيلزم إجراء تحليل للموازنة بين التكلفة والفوائد.

الدوال المثلثية

يُعدّ أداء الدوال المثلثية ضعيفًا مقارنةً بلغة C، نظرًا لأنّ لغة Java تفرض مواصفات صارمة لنتائج العمليات الحسابية، والتي قد لا تتوافق مع التنفيذ الفعلي للأجهزة. [ 65 ] في مجموعة x87 الفرعية للفاصلة العائمة، تُجري Java منذ الإصدار 1.4 عملية اختزال الوسائط لدالتي sin و cos برمجيًا، [ 66 ] مما يُسبب انخفاضًا كبيرًا في الأداء للقيم خارج النطاق. [ 67 ]

واجهة جافا الأصلية

تُسبب واجهة جافا الأصلية (JNA) عبئًا كبيرًا، مما يجعل عبور الحدود بين الكود المُشغّل على JVM والكود الأصلي مكلفًا. [ 68 ] [ 69 ] [ 70 ] توفر واجهة جافا الأصلية للوصول (JNA) لبرامج جافا وصولًا سهلًا إلى المكتبات المشتركة الأصلية ( مكتبات الارتباط الديناميكي (DLLs) على نظام ويندوز) عبر كود جافا فقط، دون الحاجة إلى JNI أو كود أصلي. تُضاهي هذه الوظيفة وظيفة Platform/Invoke في ويندوز ووظيفة ctypes في بايثون . يكون الوصول ديناميكيًا أثناء التشغيل دون توليد الكود. لكن لهذا تكلفة، وعادةً ما تكون JNA أبطأ من JNI. [ 71 ]

واجهة المستخدم

يُنظر إلى Swing على أنه أبطأ من مجموعات أدوات واجهة المستخدم الرسومية الأصلية ، لأنه يُوكل عملية عرض عناصر واجهة المستخدم الرسومية إلى واجهة برمجة تطبيقات Java ثنائية الأبعاد . ومع ذلك، تُظهر الاختبارات المعيارية التي تقارن أداء Swing مقابل مجموعة أدوات واجهة المستخدم الرسومية القياسية ، التي تُوكل عملية العرض إلى مكتبات واجهة المستخدم الرسومية الأصلية لنظام التشغيل، عدم وجود فائز واضح، وتعتمد النتائج بشكل كبير على السياق والبيئات. [ 72 ] بالإضافة إلى ذلك، يُعالج إطار عمل JavaFX الأحدث ، المُصمم ليحل محل Swing، العديد من المشكلات المتأصلة في Swing.

يُستخدم للحوسبة عالية الأداء

يعتقد البعض أن أداء جافا في الحوسبة عالية الأداء (HPC) مماثل لأداء فورتران في معايير الأداء الحسابية المكثفة، ولكن لا تزال آلات جافا الافتراضية (JVMs) تعاني من مشاكل في قابلية التوسع لإجراء اتصالات مكثفة على شبكة الحوسبة الشبكية . [ 73 ]

مع ذلك، فازت تطبيقات الحوسبة عالية الأداء المكتوبة بلغة جافا في مسابقات قياس الأداء. ففي عامي 2008 [ 74 ] و2009 [ 75 ] [ 76 ] ، تمكنت مجموعة حوسبة قائمة على أباتشي هادوب (مشروع حوسبة عالي الأداء مفتوح المصدر مكتوب بلغة جافا) من فرز تيرابايت وبيتابايت من الأعداد الصحيحة بأسرع وقت. لكن لم يكن إعداد الأجهزة للأنظمة المتنافسة ثابتًا. [ 77 ] [ 78 ]

في مسابقات البرمجة

تبدأ البرامج المكتوبة بلغة جافا ببطء مقارنةً بالبرامج المكتوبة بلغات البرمجة الأخرى. [ 79 ] [ 80 ] ولذلك، تستخدم بعض أنظمة التحكيم الإلكترونية، ولا سيما تلك التي تستضيفها الجامعات الصينية، حدودًا زمنية أطول لبرامج جافا [ 81 ] [ 82 ] [ 83 ] [ 84 ] [ 85 ] لضمان العدالة للمتسابقين الذين يستخدمون جافا.

انظر أيضاً

الاقتباسات

  1. ↑ "مقارنة بين معايير الأداء في Java و C++" .
  2. 1 2 "سيتم دمج مُترجم جافا الفوري من سيمانتك في صن جيه دي كيه 1.1" . مؤرشف من الأصل في 28 يونيو 2010.
  3. ↑ "ملخص سريع: أبل ترخص برنامج الترجمة الفورية من سيمانتك" . cnet.com. ١٢ مايو ١٩٩٨. تم الاطلاع عليه بتاريخ ١٥ نوفمبر ٢٠١٥ .
  4. ↑ "تصبح لغة جافا أسرع بأربع مرات مع مُترجم Symantec الجديد في الوقت المناسب" .{{cite web}}: CS1 maint: deprecated archiveal service ( link )
  5. ↑ "مقارنة أداء أوقات تشغيل Java/.NET (أكتوبر 2004)" .
  6. ↑ كاواغوتشي، كوهسوكي (30 مارس 2008). "نظرة معمقة على كود التجميع من جافا" . مؤرشف من الأصل في 2 أبريل 2008. تم الاطلاع عليه في 2 أبريل 2008 .
  7. ↑ "توليد سريع وفعال للتعليمات البرمجية في مُترجم جافا الفوري" (ملف PDF) . شركة إنتل . تم الاطلاع عليه بتاريخ 22 يونيو 2007 .
  8. ↑ توضح هذه المقالة أن تحسن الأداء بين الوضع التفسيري و Hotspot يصل إلى أكثر من عامل 10.
  9. ↑ الأداء العددي في لغات C و C# و Java
  10. ↑ مقارنة الأداء الخوارزمي بين لغات البرمجة C و C++ و Java و C# ( مؤرشفة في 31 مارس 2010 على موقع Wayback Machine)
  11. ↑ "آلة جافا هوت سبوت الافتراضية، الإصدار 1.4.1" . صن مايكروسيستمز . تم الاطلاع عليه بتاريخ 20 أبريل 2008 .
  12. ↑ ناتر، تشارلز (28 يناير 2008). "Lang.NET 2008: أفكار اليوم الأول" . تم الاطلاع عليه في 18 يناير 2011. يُعدّ إلغاء التحسين أمرًا مثيرًا للاهتمام عند التعامل مع مخاوف الأداء، لأنه يعني أنه يمكنك إجراء تحسينات أكثر فعالية... مع العلم أنه يمكنك العودة إلى مسار آمن ومُجرّب لاحقًا.
  13. ↑ مكتبة IBM DeveloperWorks
  14. ↑ على سبيل المثال، أصبحت مدة التوقفات أقل وضوحًا الآن. انظر على سبيل المثال إلى هذه النسخة المقلدة من لعبة Quake II المكتوبة بلغة Java: Jake2 .
  15. ↑ "ميزة جديدة في Java SE 6: مدقق التحقق من النوع" . Java.net . تم الاطلاع عليه في 18 يناير 2011 .
  16. ↑ برايان غوتز (18 أكتوبر 2005). "نظرية جافا وتطبيقها: تحسينات التزامن في موستانج" . آي بي إم . تم الاطلاع عليه في 26 يناير 2013 .
  17. ↑ "تحسينات أداء الآلة الافتراضية لـ Java HotSpot" . شركة أوراكل . تاريخ الاسترجاع: 14 يناير 2014. تحليل الهروب هو أسلوب يمكّن مُصرّف خادم Java Hotspot من تحليل نطاق استخدامات كائن جديد وتحديد ما إذا كان سيتم تخصيصه في كومة Java. يدعم Java SE 6u23 والإصدارات الأحدث تحليل الهروب ويُفعّله افتراضيًا.
  18. ↑ تقرير عن خطأ: مُخصِّص سجلات جديد، تم إصلاحه في موستانج (JDK 6) b59
  19. ↑ عميل HotSpot الخاص بـ Mustang أصبح أسرع بنسبة 58%! مؤرشف في 5 مارس 2012، على Wayback Machine في مدونة Osvaldo Pinali Doederlein على java.net
  20. ↑ مشاركة بيانات الفئة على java.sun.com
  21. ↑ مشاركة بيانات الفئات في JDK 1.5.0 في منتدى Java Buzz على موقع مطوري Artima
  22. ↑ ماكاي، نيالي. "جافا تصبح أسرع بأربع مرات مع مترجم سيمانتك الجديد في الوقت المناسب" .
  23. ↑ نظرة عامة من Sun على تحسينات الأداء بين الإصدارين 1.4 و 5.0.
  24. ↑ STR-Crazier: تحسينات الأداء في موستانج، مؤرشف في 5 يناير 2007، في Wayback Machine في مدونة كريس كامبل على java.net
  25. ↑ انظر هنا للاطلاع على معيار يوضح تحسنًا في الأداء بنسبة 60% تقريبًا عند الانتقال من Java 5.0 إلى 6 لتطبيق JFreeChart
  26. ↑ ورقة بيضاء حول أداء Java SE 6 على الرابط http://java.sun.com
  27. 1 2 هاس، تشيت (مايو 2007). " بيئة تشغيل جافا للمستهلك: تقنية جافا أكثر كفاءة وفعالية" . صن مايكروسيستمز . تم الاطلاع عليه في 27 يوليو 2007. على مستوى نظام التشغيل، يجب قراءة كل هذه الميغابايتات من القرص، وهي عملية بطيئة للغاية. في الواقع، يكمن السبب الرئيسي في وقت البحث على القرص؛ فقراءة الملفات الكبيرة بالتسلسل سريعة نسبيًا، لكن البحث عن البتات التي نحتاجها فعليًا ليس كذلك. لذا، على الرغم من أننا نحتاج فقط إلى جزء صغير من البيانات في هذه الملفات الكبيرة لأي تطبيق معين، فإن حقيقة أننا نبحث في جميع أنحاء الملفات تعني وجود نشاط كبير على القرص.
  28. ↑ هاس، تشيت (مايو 2007). "بيئة تشغيل جافا للمستهلك: تقنية جافا أكثر كفاءة وفعالية" . صن مايكروسيستمز . تم الاطلاع عليه في 27 يوليو 2007 .
  29. ↑ هاس، تشيت (مايو 2007). "بيئة تشغيل جافا للمستهلك: تقنية جافا أكثر كفاءة وفعالية" . صن مايكروسيستمز . تم الاطلاع عليه في 27 يوليو 2007 .
  30. ↑ كامبل، كريس (7 أبريل 2007). "تسريع جافا ثنائي الأبعاد باستخدام التظليل" . مؤرشف من الأصل في 5 يونيو 2011. تم الاطلاع عليه في 18 يناير 2011 .
  31. ↑ هاس، تشيت (مايو 2007). "بيئة تشغيل جافا للمستهلك: تقنية جافا أكثر كفاءة وفعالية" . صن مايكروسيستمز . تم الاطلاع عليه في 27 يوليو 2007 .
  32. ↑ "JSR 292: دعم اللغات ذات الكتابة الديناميكية على منصة جافا" . jcp.org . تم الاطلاع عليه بتاريخ 28 مايو 2008 .
  33. ↑ غوتز، برايان (4 مارس 2008). "نظرية جافا وتطبيقها: الجزء الثاني" . آي بي إم . تم الاطلاع عليه في 9 مارس 2008 .
  34. ↑ لوريمر، آر جيه (21 مارس 2008). "التوازي باستخدام Fork/Join في جافا 7" . infoq.com . تم الاطلاع عليه في 28 مايو 2008 .
  35. ↑ "تحسينات جديدة للمترجم في آلة جافا هوت سبوت الافتراضية" (ملف PDF) . صن مايكروسيستمز. مايو 2006. تم الاطلاع عليه في 30 مايو 2008 .
  36. ↑ همبل، تشارلز (13 مايو 2008). "JavaOne: Garbage First" . infoq.com . تم الاطلاع عليه في 7 سبتمبر 2008 .
  37. ↑ كوارد، داني (12 نوفمبر 2008). "آلة جافا الافتراضية: تجربة جامع قمامة جديد لـ JDK 7" . مؤرشف من الأصل في 8 ديسمبر 2011. تم الاطلاع عليه في 15 نوفمبر 2008 .
  38. ↑ "لعبة قياس أداء لغات البرمجة" . benchmarksgame.alioth.debian.org. مؤرشف من الأصل بتاريخ 25 يناير 2015. تم الاطلاع عليه بتاريخ 2 يونيو 2011 .
  39. ↑ "لعبة قياس أداء لغات البرمجة" . benchmarksgame.alioth.debian.org. مؤرشف من الأصل بتاريخ 13 يناير 2015. تم الاطلاع عليه بتاريخ 2 يونيو 2011 .
  40. ↑ "لعبة قياس أداء لغات البرمجة" . benchmarksgame.alioth.debian.org. مؤرشف من الأصل بتاريخ 10 يناير 2015. تم الاطلاع عليه بتاريخ 2 يونيو 2011 .
  41. ↑ "لعبة قياس أداء لغات البرمجة" . benchmarksgame.alioth.debian.org. مؤرشف من الأصل في 2 يناير 2015. تم الاطلاع عليه في 2 يونيو 2011 .
  42. ↑
    260/250 إطار/ثانية مقابل 245 إطار/ثانية (انظر المعيار )
  43. ↑ هوندت، روبرت. "التعرف على الحلقات في لغات C++/Java/Go/Scala" (ملف PDF) . أيام سكالا 2011. ستانفورد، كاليفورنيا . تم الاطلاع عليه بتاريخ 23 مارس 2014 .
  44. ↑ ل. غيراردي؛ د. بروغالي؛ د. كوموتي (2012). "تقييم أداء جافا مقابل سي++: معيار نمذجة ثلاثية الأبعاد" (ملف PDF) . جامعة بيرغامو . تاريخ الاسترجاع: 23 مارس 2014. باستخدام مُصرّف الخادم، المُحسَّن خصيصًا للتطبيقات طويلة الأمد، تبيّن أن جافا أبطأ من 1.09 إلى 1.91 مرة (...) في الختام، تشير النتائج المُتحصَّل عليها باستخدام مُصرّف الخادم وهذه الميزات المهمة إلى إمكانية اعتبار جافا بديلاً مناسبًا للغة سي++
  45. ↑ لويس، جيه بي؛ نيومان، أولريش. "أداء جافا مقابل سي++" . مختبر رسومات الحاسوب والتكنولوجيا الغامرة، جامعة جنوب كاليفورنيا.
  46. ↑ "محرك أداء Java HotSpot: مثال على تضمين الأساليب" . شركة أوراكل . تم الاطلاع عليه في 11 يونيو 2011 .
  47. ↑ ناتر، تشارلز (3 مايو 2008). "قوة JVM" . تم الاطلاع عليه في 11 يونيو 2011. ماذا يحدث إذا قمتَ بتضمين دالة A مسبقًا ثم ظهرت دالة B؟ هنا أيضًا يبرز دور JVM . نظرًا لأن JVM هو في الأساس بيئة تشغيل لغة ديناميكية، فإنه يظل متيقظًا دائمًا، يراقب حدوث مثل هذه الأحداث تحديدًا. وهنا الجزء الرائع حقًا: عندما تتغير الظروف، يمكن لـ JVM إلغاء التحسين. هذه تفصيلة بالغة الأهمية. العديد من بيئات التشغيل الأخرى لا يمكنها إجراء التحسين إلا مرة واحدة. يجب على مُجمِّعات لغة C القيام بكل شيء مسبقًا، أثناء عملية البناء. يسمح لك بعضها بتحليل أداء تطبيقك واستخدام ذلك في عمليات البناء اللاحقة، ولكن بمجرد إصدار جزء من التعليمات البرمجية، يكون قد وصل إلى أقصى درجة من التحسين. توجد في أنظمة أخرى شبيهة بالآلات الافتراضية، مثل CLR، مرحلة JIT، لكنها تحدث في وقت مبكر من التنفيذ (ربما قبل أن يبدأ النظام بالتنفيذ أصلاً) ولا تتكرر أبدًا. تمنح قدرة JVM على إلغاء التحسين والعودة إلى التفسير مجالًا للتفاؤل... مجالًا لوضع تخمينات طموحة والعودة بسلاسة إلى حالة آمنة، للمحاولة مرة أخرى لاحقًا.
  48. ↑ "التقييم الدقيق للغات C++ وC# وجافا: العمليات الحسابية للأعداد الصحيحة 32 بت" . مجلة دكتور دوبز . 1 يوليو 2005. تم الاطلاع عليه في 18 يناير 2011 .
  49. ↑ "التقييم الدقيق للغات C++ وC# وجافا: العمليات الحسابية المزدوجة 64 بت" . مجلة دكتور دوبز . 1 يوليو 2005. تم الاطلاع عليه في 18 يناير 2011 .
  50. ↑ "التقييم الدقيق لـ C++ و C# و Java: عمليات الإدخال والإخراج للملفات" . مجلة دكتور دوبز . 1 يوليو 2005. تم الاطلاع عليه في 18 يناير 2011 .
  51. ↑ "التقييم الدقيق للغات C++ وC# وJava: استثناء" . مجلة دكتور دوبز . 1 يوليو 2005. تم الاطلاع عليه في 18 يناير 2011 .
  52. ↑ "التقييم الدقيق لـ C++ و C# و Java: المصفوفات" . مجلة دكتور دوب . 1 يوليو 2005. تم الاطلاع عليه في 18 يناير 2011 .
  53. ↑ "التقييم الدقيق لوظائف C++ وC# وJava: الدوال المثلثية" . مجلة دكتور دوبز . 1 يوليو 2005. تم الاطلاع عليه بتاريخ 18 يناير 2011 .
  54. ↑ يي تشاو، جين شي، كاي تشنغ، هايتشوان وانغ، هايبو لين ولينغ شاو، جدار التخصيص: عامل مقيد لتطبيقات جافا على منصات متعددة النوى الناشئة ، وقائع المؤتمر الرابع والعشرين لـ ACM SIGPLAN حول لغات وأنظمة البرمجة الموجهة للكائنات، 2009.
  55. ↑ "C4: جامع الضغط المتزامن المستمر" (ملف PDF) . مؤرشف من الأصل (ملف PDF) في 9 أغسطس 2014. تم الاطلاع عليه في 29 أكتوبر 2013 .
  56. ↑ أزول يتفوق على جافا بجهاز ذي 768 نواة
  57. ↑ "قياس أداء بدء التشغيل والنظام لـ .Net و Mono و Java و C++ وواجهات المستخدم الخاصة بها" . 2 سبتمبر 2010.
  58. ↑ "ما مدى سرعة المُدقِّق الجديد؟" . 7 فبراير 2006. مؤرشف من الأصل في 16 مايو 2006. تم الاطلاع عليه في 9 مايو 2007 .
  59. ↑ مسدس المسامير
  60. ↑ توضح صفحة خلفية مسدس المسامير " أفضل سيناريو " تسريعًا بمقدار 33 مرة (للبرامج المكتوبة "Hello, World!" أي البرامج قصيرة التشغيل).
  61. ↑ "كيفية حساب استخدام الذاكرة لكائنات جافا" .
  62. ↑ "دليل مرجعي للغة C++ من InformIT > نموذج الكائنات" . مؤرشف من الأصل بتاريخ 21 فبراير 2008. تم الاطلاع عليه بتاريخ 22 يونيو 2009 .
  63. ↑ https://www.youtube.com/watch?v=M91w0SBZ-wc  : فهم عملية جمع البيانات المهملة في جافا - محاضرة لجيل تين في مؤتمر JavaOne
  64. ↑ ".: أنظمة ToMMTi :: Hinter den Kulissen Moderner 3D-Hardware" . 
  65. ↑ "الرياضيات (منصة جافا SE 6)" . صن مايكروسيستمز . تم الاطلاع عليه في 8 يونيو 2008 .
  66. ↑ جوسلينج، جيمس (27 يوليو 2005). "التأمل التجاوزي" . مؤرشف من الأصل في 12 أغسطس 2011. تم الاطلاع عليه في 8 يونيو 2008 .
  67. ↑ كويل-شاه، كريستوفر و. (8 يناير 2004). "ملخص أداء تسع لغات: قياس أداء العمليات الحسابية وإدخال/إخراج الملفات" . مؤرشف من الأصل في 11 أكتوبر 2018. تم الاطلاع عليه في 8 يونيو 2008 .
  68. ↑ ويلسون، ستيف؛ جيف كيسلمان (2001). "أداء منصة جافا: استخدام التعليمات البرمجية الأصلية" . صن مايكروسيستمز . تم الاسترجاع في 15 فبراير 2008 .
  69. ↑ كورزينيك، داويد؛ فايدي سوندرام. "التعاون الفعال بين جافا والبرمجيات الأصلية - معيار أداء JNI" (ملف PDF) . مؤرشف من الأصل (ملف PDF) بتاريخ 14 فبراير 2005. تم الاطلاع عليه بتاريخ 15 فبراير 2008 .
  70. ↑ بلوخ 2018 ، ص 285، الفصل §11 البند 66: استخدم الأساليب الأصلية بحكمة.
  71. ↑ "كيف تتم مقارنة أداء JNA بأداء JNI المخصص؟" . صن مايكروسيستمز . تم الاطلاع عليه بتاريخ 26 ديسمبر 2009 .
  72. ↑ إيغور، كريزنار (10 مايو 2005). "مقارنة أداء SWT وSwing" ( ملف PDF) . cosylab.com. مؤرشف من الأصل (ملف PDF) في 4 يوليو 2008. تم الاطلاع عليه في 24 مايو 2008. من الصعب وضع قاعدة عامة تحدد متى يتفوق SWT على Swing، أو العكس. في بعض البيئات (مثل Windows)، يكون SWT هو الأفضل. في بيئات أخرى (Linux، و VMware التي تستضيف Windows)، يتفوق Swing وتحسين إعادة الرسم الخاص به على SWT بشكل ملحوظ. الاختلافات في الأداء كبيرة: من الشائع أن تكون عوامل 2 أو أكثر، في كلا الاتجاهين.
  73. ↑ برايان أميدرو؛ فلاديمير بودنارتشوك؛ دينيس كاروميل؛ كريستيان ديلبي؛ فابريس هويه؛ غييرمو ل. تابوادا (أغسطس 2008). " الوضع الحالي لجافا للحوسبة عالية الأداء" . INRIA . تم الاطلاع عليه في 9 سبتمبر 2008. أجرينا أولًا بعض الاختبارات المعيارية الدقيقة لمختلف آلات جافا الافتراضية، مُظهرين الأداء الجيد عمومًا للعمليات الحسابية الأساسية (...). وبمقارنة هذا التطبيق مع تطبيق Fortran/MPI، أظهرنا أنهما يتمتعان بأداء مماثل في الاختبارات المعيارية كثيفة الحساب، ولكنهما لا يزالان يعانيان من مشكلات قابلية التوسع عند إجراء اتصالات مكثفة.
  74. ↑ أوين أومالي - فريق الحوسبة الشبكية في ياهو! (يوليو 2008). "أباتشي هادوب يفوز في اختبار معياري لفرز البيانات بحجم تيرابايت" . مؤرشف من الأصل في 15 أكتوبر 2009. تم الاطلاع عليه في 21 ديسمبر 2008. هذه هي المرة الأولى التي يفوز فيها برنامج مكتوب بلغة جافا أو برنامج مفتوح المصدر.
  75. ↑ "هادوب يُرتب بيتابايت في 16.25 ساعة وتيرابايت في 62 ثانية" . CNET.com . 11 مايو 2009. مؤرشف من الأصل في 16 مايو 2009. تم الاطلاع عليه في 8 سبتمبر 2010. تفاصيل الأجهزة ونظام التشغيل هي: (...) Sun Java JDK (1.6.0_05-b13 و1.6.0_13-b03) (32 و64 بت)
  76. ↑ "هادوب يحطم الأرقام القياسية العالمية في فرز البيانات" . CNET.com . 15 مايو 2009. تم الاطلاع عليه في 8 سبتمبر 2010 .
  77. ↑ كريس نيبرغ؛ ميهول شاه. "الصفحة الرئيسية لمعيار الفرز" . تم الاطلاع عليه في 30 نوفمبر 2010 .
  78. ^ تشايكوفسكي ، جرزيجورز (21 نوفمبر 2008). "فرز 1PB باستخدام MapReduce" . تم الاسترجاع 1 ديسمبر، 2010 .
  79. ↑ "TCO10" . مؤرشف من الأصل بتاريخ 18 أكتوبر 2010. تم الاطلاع عليه بتاريخ 21 يونيو 2010 .
  80. ↑ "كيفية كتابة حلول جافا @ Timus Online Judge" .
  81. ↑ "الأسئلة الشائعة" .
  82. ↑ "الأسئلة الشائعة | محكم TJU ACM-ICPC عبر الإنترنت" . مؤرشف من الأصل في 29 يونيو 2010. تم الاطلاع عليه في 25 مايو 2010 .
  83. ↑ "الأسئلة الشائعة | CodeChef" .
  84. ↑ "الصفحة الرئيسية لمنصة التحكيم الإلكتروني لجامعة شيان الإلكترونية" . مؤرشفة من الأصل بتاريخ 19 فبراير 2012. تم الاطلاع عليها بتاريخ 13 نوفمبر 2011 .
  85. ↑ "الأسئلة الشائعة" .

مراجع

  • بلوخ، جوشوا (2018). "جافا الفعّالة: دليل لغة البرمجة" (  الطبعة الثالثة). أديسون-ويسلي. ISBN 978-0134685991.