java - অ্যারেস.ফিল() আর কেন হ্যাশম্যাপ.ক্লায়ার() এ ব্যবহার হয় না?




arrays hashmap (4)

2 সংস্করণের লুপের মধ্যে কার্যকারিতাটিতে কোনও আসল পার্থক্য নেই। Arrays.fill ঠিক একই জিনিসটি করে।

সুতরাং এটি ব্যবহার বা না করার পছন্দটি অগত্যা ভুল হিসাবে বিবেচিত হবে না। এই ধরণের মাইক্রো ম্যানেজমেন্টের বিষয়টি কখন আসে তা বিকাশকারীকে ছেড়ে দেওয়া হয়।

প্রতিটি পদ্ধতির জন্য দুটি পৃথক উদ্বেগ রয়েছে:

  • Arrays.fill ব্যবহার করে কোডটি কম ভার্বোস এবং আরও পাঠযোগ্য।
  • HashMap কোডে সরাসরি লুপিং (সংস্করণ 8 এর মতো) পারফরম্যান্স ওয়াইস আসলে আরও ভাল বিকল্প। Arrays ক্লাসটি সন্নিবেশ করানো ওভারহেডটি যদিও নগণ্য তবে যখন এটি HashMap মতো বিস্তৃত কিছুতে আসে তখন যেখানে পারফরম্যান্স বর্ধনের প্রতিটি বিটই বড় প্রভাব ফেলে (কল্পনা করুন ফুলব্লাউন ওয়েব অ্যাপে হ্যাশম্যাপ হ্রাস করার ক্ষুদ্রতম পদচিহ্ন)। অ্যারে ক্লাসটি শুধুমাত্র এই এক লুপের জন্য ব্যবহৃত হয়েছিল তা বিবেচনা করুন। পরিবর্তনটি যথেষ্ট ছোট যা এটি পরিষ্কার পদ্ধতিটিকে কম পাঠযোগ্য করে তোলে না।

বিকাশকারী কে আসলে এটি করেছে জিজ্ঞাসা না করে সুনির্দিষ্ট কারণটি খুঁজে পাওয়া যায় না, তবে আমার সন্দেহ হয় এটি ভুল বা একটি ছোট বর্ধন। ভাল বিকল্প।

আমার অভিমত এটিকে একটি বর্ধন হিসাবে বিবেচনা করা যেতে পারে, এমনকি যদি দুর্ঘটনাক্রমেও ঘটে।

আমি HashMap.clear() প্রয়োগের ক্ষেত্রে অদ্ভুত কিছু লক্ষ্য করেছি। এটি ওপেনজেডিকে 7u40 তে দেখেছিল :

public void clear() {
    modCount++;
    Arrays.fill(table, null);
    size = 0;
}

ওপেনজেডিকে 8u40 এর মতো দেখতে এটি:

public void clear() {
    Node<K,V>[] tab;
    modCount++;
    if ((tab = table) != null && size > 0) {
        size = 0;
        for (int i = 0; i < tab.length; ++i)
            tab[i] = null;
    }
}

আমি বুঝতে পেরেছি যে এখন table খালি মানচিত্রের জন্য শূন্য হতে পারে, সুতরাং স্থানীয় ভেরিয়েবলের অতিরিক্ত চেক এবং ক্যাশিং প্রয়োজন। তবে কেন Arrays.fill() একটি লুপ দিয়ে প্রতিস্থাপন করা হলো?

মনে হচ্ছে এই প্রতিশ্রুতিতে পরিবর্তনটি চালু হয়েছিল। দুর্ভাগ্যক্রমে আমি লুপের জন্য একটি সমতল কেন Arrays.fill() চেয়ে ভাল হতে পারে তার কোনও ব্যাখ্যা Arrays.fill() । এটা কি দ্রুত? নাকি নিরাপদ?


আমার জন্য, কারণটি কোডের স্বচ্ছতার ক্ষেত্রে নগণ্য ব্যয়ে সম্ভাব্য পারফরম্যান্স ইনগ্রোভমেন্ট।

নোট করুন যে fill পদ্ধতিটি বাস্তবায়ন তুচ্ছ, প্রতিটি অ্যারে উপাদান নালায় সেট করার জন্য একটি সরল লুপ। সুতরাং, কলটির প্রকৃত প্রয়োগের সাথে প্রতিস্থাপন কলার পদ্ধতির স্পষ্টতা / সংক্ষিপ্ততায় কোনও উল্লেখযোগ্য অবক্ষয়ের কারণ নয়।

সম্ভাব্য পারফরম্যান্স সুবিধাগুলি এতটা তুচ্ছ নয়, যদি আপনি এর সাথে জড়িত সমস্ত বিষয় বিবেচনা করেন:

  1. জেভিএমের Arrays ক্লাসটি সমাধান করার প্রয়োজন হবে না, প্রয়োজনে এটি লোড করা এবং আরম্ভ করার দরকার নেই। এটি একটি অ-তুচ্ছ প্রক্রিয়া যেখানে জেভিএম বেশ কয়েকটি পদক্ষেপ সম্পাদন করে। প্রথমত, ক্লাস লোডারটি ক্লাসটি ইতিমধ্যে লোড হয়েছে কিনা তা পরীক্ষা করে দেখায় এবং প্রতিবারই কোনও পদ্ধতি বলা হওয়ার পরে এটি ঘটে; অবশ্যই এখানে জড়িত অপ্টিমাইজেশন রয়েছে, তবে এটি এখনও কিছু প্রচেষ্টা গ্রহণ করে। যদি শ্রেণিটি লোড না করা হয়, জেভিএমকে এটি লোড করার ব্যয়বহুল প্রক্রিয়াটি অনুসরণ করা, বাইটকোড যাচাই করা, অন্যান্য প্রয়োজনীয় নির্ভরতাগুলি সমাধান করা এবং শেষ পর্যন্ত শ্রেণীর স্ট্যাটিক ইনিশিয়ালেশন সম্পাদন করা (যা নির্বিচারে ব্যয়বহুল হতে পারে) করা প্রয়োজন। HashMap যেমন একটি মূল শ্রেণি, এবং Arrays এমন বিশাল শ্রেণি (3600+ লাইন), এই ব্যয়গুলি এড়িয়ে যাওয়া লক্ষণীয় সঞ্চয়কে আরও বাড়িয়ে দিতে পারে Give

  2. যেহেতু কোনও Arrays.fill(...) পদ্ধতি কল নেই, তাই Arrays.fill(...) সিদ্ধান্ত নিতে হবে না যে / কখন এই পদ্ধতিটি কলারের শরীরে প্রবেশ করানো হবে। যেহেতু HashMap#clear() অনেক কল করার প্রবণতা রয়েছে, জেভিএম শেষ পর্যন্ত ইনলাইনিংটি সম্পাদন করবে, যার জন্য clear পদ্ধতিটির জেআইটি পুনঃনির্মাণের প্রয়োজন। কোনও মেথড কল ছাড়াই clear সর্বদা দ্রুতগতিতে চলবে (একবার প্রাথমিকভাবে জেআইটিড করা হবে)।

Arrays আর কল করার পদ্ধতিগুলির আর একটি সুবিধা হ'ল এটি java.util প্যাকেজের অভ্যন্তরের নির্ভরতা গ্রাফকে সহজতর করে, যেহেতু একটি নির্ভরতা অপসারণ করা হয়।


আমি মন্তব্যে প্রস্তাবিত তিনটি আরোহীন যুক্তিসঙ্গত সংস্করণ সংক্ষিপ্ত করার চেষ্টা করব।

@ হোলজার says :

আমি অনুমান করি যে এটি জাভা.ইটি.এল ক্লাস এড়ানোর জন্য এই পদ্ধতিটির পার্শ্ব প্রতিক্রিয়া হিসাবে লোড হচ্ছে getting অ্যাপ্লিকেশন কোডের জন্য, এটি সাধারণত উদ্বেগের বিষয় নয়।

এটি পরীক্ষা করা সবচেয়ে সহজ জিনিস। আসুন এই জাতীয় প্রোগ্রাম সংকলন করা যাক:

public class HashMapTest {
    public static void main(String[] args) {
        new java.util.HashMap();
    }
}

এটি java -verbose:class HashMapTest দিয়ে চালান java -verbose:class HashMapTest । এটি ক্লাস লোডিং ইভেন্টগুলি হওয়ার সাথে সাথে মুদ্রণ করবে। JDK 1.8.0_60 এর সাথে আমি 400 টিরও বেশি ক্লাস লোড দেখতে পেয়েছি:

... 155 lines skipped ...
[Loaded java.util.Set from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.AbstractSet from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.Collections$EmptySet from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.Collections$EmptyList from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.Collections$EmptyMap from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.Collections$UnmodifiableCollection from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.Collections$UnmodifiableList from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.Collections$UnmodifiableRandomAccessList from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded sun.reflect.Reflection from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
**[Loaded java.util.HashMap from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.HashMap$Node from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.lang.Class$3 from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.lang.Class$ReflectionData from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.lang.Class$Atomic from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded sun.reflect.generics.repository.AbstractRepository from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded sun.reflect.generics.repository.GenericDeclRepository from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded sun.reflect.generics.repository.ClassRepository from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.lang.Class$AnnotationData from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded sun.reflect.annotation.AnnotationType from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.util.WeakHashMap from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.lang.ClassValue$ClassValueMap from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.lang.reflect.Modifier from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded sun.reflect.LangReflectAccess from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
[Loaded java.lang.reflect.ReflectAccess from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
**[Loaded java.util.Arrays from C:\Program Files\Java\jre1.8.0_60\lib\rt.jar]
...

আপনি দেখতে পাচ্ছেন, অ্যাপ্লিকেশন কোডের অনেক আগে HashMap লোড হয়ে গেছে এবং HashMap পরে Arrays কেবল 14 ক্লাসে লোড করা হবে। HashMap লোডটি sun.reflect.Reflection দ্বারা ট্রিগার করা হয়েছে sun.reflect.Reflection HashMap স্ট্যাটিক ক্ষেত্রগুলি রয়েছে বলে sun.reflect.ReflectionArrays লোডটি WeakHashMap লোড দ্বারা ট্রিগার হওয়ার সম্ভাবনা রয়েছে যা clear() পদ্ধতিতে আসলে Arrays.fill রয়েছে। WeakHashMap লোড java.lang.ClassValue$ClassValueMap দ্বারা ট্রিগার করা হয়েছে যা WeakHashMap প্রসারিত WeakHashMapClassValueMap প্রতিটি java.lang.Class উদাহরণে উপস্থিত রয়েছে। সুতরাং আমার কাছে মনে হয় Arrays ক্লাস ছাড়া Arrays মোটেও আরম্ভ করা যাবে না। এছাড়াও Arrays স্ট্যাটিক ইনিশিয়ালাইজারটি খুব সংক্ষিপ্ত, এটি কেবলমাত্র দৃ mechanism়তা প্রক্রিয়াটি আরম্ভ করে। এই প্রক্রিয়াটি আরও অনেক ক্লাসে ব্যবহৃত হয় (উদাহরণস্বরূপ, java.lang.Throwable যা খুব তাড়াতাড়ি লোড হয়)। java.util.Arrays কোনও স্থিতিশীল আরম্ভের কোনও পদক্ষেপ সম্পাদিত হয় না। এইভাবে @ হোলজার সংস্করণটি আমার কাছে ভুল বলে মনে হচ্ছে।

এখানে আমরা খুব আকর্ষণীয় জিনিস পেয়েছি। WeakHashMap.clear() এখনও Arrays.fill ব্যবহার Arrays.fill । এটি উপস্থিত হওয়ার সময় এটি আকর্ষণীয়, তবে দুর্ভাগ্যক্রমে এটি প্রাগৈতিহাসিক সময়ে চলে যায় (এটি ইতিমধ্যে সেখানে প্রথম প্রকাশ্য ওপেনজেডিকে সংগ্রহস্থলে ছিল)।

এর পরে, @ মার্কো টপলনিক says :

নিরাপদ অবশ্যই না, তবে fill কলটি ইনলাইনড না করা এবং tab সংক্ষিপ্ত না হলে এটি আরও দ্রুত হতে পারে। হটস্পট-এ উভয় লুপ এবং সুস্পষ্ট ফিলিং কলের ফলে দ্রুত সংকলক অভ্যন্তরীণ হবে (শুভ দিনের দৃশ্যে)।

আমার জন্য এটি অবাক করে দিয়েছিল যে Arrays.fill সরাসরি Arrays.fill নয় ( @apangin দ্বারা উত্পাদিত অভ্যন্তরীণ তালিকা দেখুন)। মনে হয় যে এ জাতীয় লুপটি স্বতন্ত্র অভ্যন্তরীণ হ্যান্ডলিং ছাড়াই JVM দ্বারা স্বীকৃত এবং ভেক্টরাইজড হতে পারে। সুতরাং এটি সত্য যে অতিরিক্ত কলটি খুব নির্দিষ্ট ক্ষেত্রে MaxInlineLevel করা যায় না (উদাহরণস্বরূপ যদি MaxInlineLevel সীমাটি পৌঁছে যায়)। অন্যদিকে এটি অত্যন্ত বিরল পরিস্থিতি এবং এটি কেবল একটি একক কল, এটি লুপের অভ্যন্তরে কল নয়, এবং এটি একটি স্ট্যাটিক, ভার্চুয়াল / ইন্টারফেস কল নয়, সুতরাং পারফরম্যান্সের উন্নতি কেবলমাত্র প্রান্তিক এবং কিছু নির্দিষ্ট পরিস্থিতিতে হতে পারে। জেভিএম বিকাশকারীরা সাধারণত যে জিনিস যত্ন করে তা নয়।

এছাড়াও এটি লক্ষ করা উচিত যে এমনকি সি 1 'ক্লায়েন্ট' সংকলক (স্তরের 1-3) এছাড়াও Arrays.fill নামক ইনলাইন করতে সক্ষম, উদাহরণস্বরূপ, WeakHashMap.clear() ইনলাইনিং লগ হিসাবে ( -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation -XX:+PrintInlining ) বলেছেন:

36       3  java.util.WeakHashMap::clear (50 bytes)
     !m        @ 4   java.lang.ref.ReferenceQueue::poll (28 bytes)
                 @ 17   java.lang.ref.ReferenceQueue::reallyPoll (66 bytes)   callee is too large
               @ 28   java.util.Arrays::fill (21 bytes)
     !m        @ 40   java.lang.ref.ReferenceQueue::poll (28 bytes)
                 @ 17   java.lang.ref.ReferenceQueue::reallyPoll (66 bytes)   callee is too large
               @ 1   java.util.AbstractMap::<init> (5 bytes)   inline (hot)
                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
               @ 9   java.lang.ref.ReferenceQueue::<init> (27 bytes)   inline (hot)
                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
                 @ 10   java.lang.ref.ReferenceQueue$Lock::<init> (5 bytes)   unloaded signature classes
               @ 62   java.lang.Float::isNaN (12 bytes)   inline (hot)
               @ 112   java.util.WeakHashMap::newTable (8 bytes)   inline (hot)

অবশ্যই এটি সহজেই স্মার্ট এবং শক্তিশালী সি 2 'সার্ভার' সংকলক দ্বারা অন্তর্ভুক্ত। সুতরাং আমি এখানে কোন সমস্যা দেখতে পাচ্ছি। দেখে মনে হচ্ছে @ মারকো সংস্করণটিও ভুল।

অবশেষে আমাদের কাছে @ স্টার্টমার্কস (যিনি জেডিকে বিকাশকারী, এভাবে কিছু সরকারী ভয়েস) থেকে বেশ কয়েকটি comments পেয়েছেন:

মজাদার. আমার কুণ্ডলী এটি একটি ভুল যে। এই পরিবর্তনটির জন্য পর্যালোচনা থ্রেডটি here এবং এটি here চালিত পূর্ববর্তী থ্রেডের উল্লেখ করে। পূর্ববর্তী থ্রেডের প্রাথমিক বার্তাটি ডগ লিয়ার সিভিএস সংগ্রহস্থলে হ্যাশম্যাপ.জাবার একটি প্রোটোটাইপকে নির্দেশ করে। আমি জানি না এটি কোথা থেকে এসেছে। এটি ওপেনজেডিকে ইতিহাসের কোনও কিছুর সাথে মিলছে বলে মনে হচ্ছে না।

... যাইহোক, এটি কিছু পুরানো স্ন্যাপশট হতে পারে; লুপটি বহু বছর ধরে পরিষ্কার () পদ্ধতিতে ছিল। অ্যারেজ.ফিল () কলটি এই চেঞ্জসেট দ্বারা প্রবর্তিত হয়েছিল, তাই এটি কেবল কয়েক মাসের জন্য গাছটিতে ছিল। আরও উল্লেখ করুন যে এই পরিবর্তনটি প্রবর্তিত Integer.highestOneBit () এর উপর ভিত্তি করে পাওয়ার-অফ-টু গণনা একই সময়ে অদৃশ্য হয়ে গেছে, যদিও এটি উল্লেখ করা হয়েছিল তবে পর্যালোচনার সময় বরখাস্ত করা হয়েছে। হুম।

প্রকৃতপক্ষে HashMap.clear() বহু বছর ধরে লুপটি ধারণ করেছিল, এপ্রিল 10 এপ্রিল, 2013 এ Arrays.fill সাথে replaced হয়েছিল এবং 4 সেপ্টেম্বর অবধি আলোচিত প্রতিশ্রুতি প্রবর্তিত হওয়ার পরে কম দেড় বছর স্থায়ী ছিল। আলোচিত প্রতিশ্রুতিটি আসলে JDK-8023463 ইস্যুটি ঠিক করার জন্য HashMap ইন্টার্নালদের একটি নতুন পুনর্লিখন ছিল। এটি HashMap বিষযুক্ত করার সম্ভাবনা নিয়ে দীর্ঘ গল্প যা হ্যাশকোডের নকল হ্যাশকোডগুলির কীগুলি HashMap অনুসন্ধানের গতি লিনিয়ারে হ্রাস করে যা এটি ডস-আক্রমণের জন্য ঝুঁকিপূর্ণ করে তোলে। এটি সমাধানের প্রচেষ্টা স্ট্রিং হ্যাশকোডের কিছু এলোমেলোকরণ সহ জেডিকে-7 এ সম্পাদিত হয়েছিল। সুতরাং দেখে মনে হচ্ছে যে HashMap বাস্তবায়নটি পূর্বের প্রতিশ্রুতি থেকে স্বতন্ত্রভাবে বিকশিত হয়েছিল, তারপরে মাস্টার শাখায় একীভূত হয়েছিল এবং এর মধ্যে চালু হওয়া বেশ কয়েকটি পরিবর্তন ওভাররাইট করে।

আমরা এই অনুমানকে পার্থক্য সম্পাদন করতে পারি। যেখানে Arrays.fill সরানো হয়েছিল (2013-09-04) version নিন এবং এটি পূর্ববর্তী সংস্করণ (2013-07-30) এর সাথে তুলনা করুন। diff -U0 আউটপুটটিতে 4341 টি লাইন রয়েছে। এখন Arrays.fill হওয়ার আগে version বিপরীতে আসুন (2013-04-01) এখন diff -U0 কেবল 2680 টি লাইন রয়েছে। সুতরাং নতুন সংস্করণটি তাত্ক্ষণিক পিতামাতার চেয়ে পুরানোগুলির সাথে বেশি মিল।

উপসংহার

সুতরাং উপসংহারে আমি স্টুয়ার্ট মার্কসের সাথে একমত হব। Arrays.fill সরানোর Arrays.fill concrete Arrays.fill কারণ ছিল না, এটি কেবলমাত্র কারণ মধ্যবর্তী পরিবর্তনটি ভুলক্রমে ওভাররাইট হয়েছিল। Arrays.fill ব্যবহার করা Arrays.fill কোড এবং ব্যবহারকারী অ্যাপ্লিকেশনগুলিতে পুরোপুরি সূক্ষ্ম এবং উদাহরণস্বরূপ, WeakHashMapArrays ক্লাসটি JDK ইনিশিয়ালেশন চলাকালীন খুব তাড়াতাড়ি লোড করা হয়, খুব সাধারণ স্ট্যাটিক ইনিশিয়ালাইজার রয়েছে এবং Arrays.fill পদ্ধতিটি ক্লায়েন্ট সংকলক দ্বারা সহজেই Arrays.fill যেতে পারে, সুতরাং কোনও পারফরম্যান্সের অপূর্ণতা লক্ষ করা উচিত নয়।


কারণ এটি অনেক দ্রুত!

আমি দুটি পদ্ধতির কাটা ডাউন সংস্করণ সম্পর্কে কিছু পুঙ্খানুপুঙ্খ বেঞ্চমার্কিং পরীক্ষা চালিয়েছি:

void jdk7clear() {
    Arrays.fill(table, null);
}

void jdk8clear() {
    Object[] tab;
    if ((tab = table) != null) {
        for (int i = 0; i < tab.length; ++i)
            tab[i] = null;
    }
}

এলোমেলো মান সহ বিভিন্ন আকারের অ্যারেগুলিতে অপারেটিং। এখানে (সাধারণ) ফলাফল:

Map size |  JDK 7 (sd)|  JDK 8 (sd)| JDK 8 vs 7
       16|   2267 (36)|   1521 (22)| 67%
       64|   3781 (63)|   1434 ( 8)| 38%
      256|   3092 (72)|   1620 (24)| 52%
     1024|   4009 (38)|   2182 (19)| 54%
     4096|   8622 (11)|   4732 (26)| 55%
    16384|  27478 ( 7)|  12186 ( 8)| 44%
    65536| 104587 ( 9)|  46158 ( 6)| 44%
   262144| 445302 ( 7)| 183970 ( 8)| 41%

নাল দ্বারা ভরা একটি অ্যারের উপর অপারেট করার সময় এবং ফলাফলগুলি এখানে রয়েছে (যাতে আবর্জনা সংগ্রহের সমস্যাগুলি মুছে ফেলা হয়):

Map size |  JDK 7 (sd)|  JDK 8 (sd)| JDK 8 vs 7
       16|     75 (15)|     65 (10)|  87%
       64|    116 (34)|     90 (15)|  78%
      256|    246 (36)|    191 (20)|  78%
     1024|    751 (40)|    562 (20)|  75%
     4096|   2857 (44)|   2105 (21)|  74%
    16384|  13086 (51)|   8837 (19)|  68%
    65536|  52940 (53)|  36080 (16)|  68%
   262144| 225727 (48)| 155981 (12)|  69%

সংখ্যাগুলি ন্যানোসেকেন্ডে রয়েছে (sd) ফলাফলের শতাংশ হিসাবে প্রকাশিত 1 স্ট্যান্ডার্ড বিচ্যুতি (ফাই, একটি "সাধারণভাবে বিতরণ করা" জনসংখ্যার একটি এসডি রয়েছে 68), vs জেডিকে 8 এর তুলনায় জেডিকে 8 সময়সাপেক্ষ।

এটি আকর্ষণীয় যে এটি কেবলমাত্র উল্লেখযোগ্যভাবে দ্রুত নয়, বিচ্যুতিটি কিছুটা সংকীর্ণও রয়েছে যার অর্থ জেডিকে 8 বাস্তবায়ন কিছুটা সামঞ্জস্যপূর্ণ কর্মক্ষমতা দেয়।

পরীক্ষাগুলি jdk 1.8.0_45 এ এ্যান্ডে এলোমেলো Integer অবজেক্টের সাথে সংখ্যক বৃহত (মিলিয়ন) সংখ্যকবার চালানো হয়েছিল। ফাঁকা সংখ্যাগুলি সরাতে, ফলাফলগুলির প্রতিটি সেটে দ্রুত এবং ধীর 3% সময় বাতিল করা হয়েছিল। আবর্জনা সংগ্রহের জন্য অনুরোধ করা হয়েছিল এবং পদ্ধতির প্রতিটি অনুরোধ চালানোর আগে থ্রেডটি উত্সাহ পেয়েছিল এবং ঘুমিয়েছিল। প্রথম 20% কাজের উপর জেভিএম ওয়ার্ম আপ করা হয়েছিল এবং ফলাফলগুলি বাতিল করা হয়েছিল।





java-8