सभी पैच समान रूप से उपयोगी नहीं हैं।

यह पोस्ट प्रदर्शन सुधारों की चर्चा जारी रखता है जो अलग-अलग ब्यूट के लिए सही नहीं थे। StringBuilder बारे में पिछला हिस्सा यहाँ है ।

यहां हम भाषा विनिर्देश, गैर-स्पष्ट कोने के मामलों और अन्य कारणों की सूक्ष्मताओं की समझ में कमी के कारण कई "सुधार" को देखते हैं। चलो चलते हैं!

जब कुछ भी मुसीबत को चित्रित नहीं करता है

मुझे लगता है कि हममें से प्रत्येक ने तरीके से काम किया है। Collections.emptyList() । Collections.emptyList() / Collections.emptyList() / Collections.emptyList() । ये बहुत उपयोगी विधियां हैं जो आपको एक नई वस्तु बनाने के बिना एक खाली अपरिवर्तनीय संग्रह को वापस करने की अनुमति देती हैं। EmptyList वर्ग के अंदर देखते हुए EmptyList हम यह देखेंगे:

 private static class EmptyList<E> { public Iterator<E> iterator() { return emptyIterator(); } public Object[] toArray() { return new Object[0]; } } 

सुधार की प्रबल संभावनाएं देखें? EmptyList.iterator() विधि उपस्थिति से एक खाली पुनरावर्तक लौटाती है, क्यों नहीं ऐरे toArray() विधि द्वारा लौटाए गए सरणी के लिए अपने कानों के साथ एक ही EmptyList.iterator() ?

दूसरे शब्दों में, विधि को हमेशा एक नया सरणी वापस करना चाहिए।

आप कहेंगे: "वह अपरिवर्तनीय है! क्या गलत हो सकता है?"

केवल अनुभवी विशेषज्ञ ही इस प्रश्न का उत्तर दे सकते हैं:

- जिम्मेदार कौन?
- जिम्मेदार विशेषज्ञ पॉल सैंडोज और टैगिर वलेव

यह कथन शायद आपको हतप्रभ कर देगा:

ई। जी। सरणी कॉल द्वारा लौटाए गए ऑब्जेक्ट पर कोई व्यक्ति सिंक्रनाइज़ कर सकता है, इसलिए यह परिवर्तन अवांछित लॉक साझाकरण का कारण हो सकता है।

आप कहेंगे: "उनके दाहिने दिमाग में कौन संग्रह से सरणी (!) पर लौटाया जाएगा (!)?"

यह बहुत विश्वसनीय नहीं लगता है, लेकिन भाषा ऐसा अवसर प्रदान करती है, जिसका अर्थ है कि एक संभावना है कि एक निश्चित उपयोगकर्ता ऐसा करेगा (या पहले से ही कर चुका है)। तब प्रस्तावित परिवर्तन कोड के व्यवहार को सबसे अच्छा बदल देगा, और सबसे खराब रूप से, यह सिंक्रनाइज़ेशन में एक टूटने की ओर ले जाएगा (बाद में जाएं, इसे पकड़ लें)। जोखिम इतना अनुचित है, और अपेक्षित लाभ इतना महत्वहीन है कि सब कुछ छोड़ देना बेहतर है जैसा कि यह है।

सामान्य तौर पर, किसी भी वस्तु, kmk पर सिंक्रनाइज़ करने की क्षमता, भाषा डेवलपर्स की गलती थी। सबसे पहले, प्रत्येक ऑब्जेक्ट के हेडर में सिंक्रोनाइज़ेशन के लिए जिम्मेदार एक संरचना होती है, और दूसरी बात, हम खुद को ऊपर वर्णित स्थिति में पाते हैं जब एक प्रतीत होता है कि अपरिवर्तनीय वस्तु को कई बार वापस नहीं किया जा सकता है, क्योंकि यह उस पर सिंक्रनाइज़ किया जा सकता है।

इस कल्पित कहानी का नैतिक यह है: विनिर्देश और पिछड़े संगतता जावा की पवित्र गाय हैं। उन पर अतिक्रमण करने का भी प्रयास न करें: गार्ड चेतावनी के बिना गोली मारता है।

कोशिश कर रहा है, कोशिश कर रहा है ...

JDK में कई सरणी-आधारित कक्षाएं एक साथ हैं, और उनमें से सभी तरीके List.indexOf() और List.lastIndexOf() लागू करते हैं:

• java.util.ArrayList
• java.util.Arays $ ArrayList
• java.util.Vector
• java.util.concurrent.CopyOnWriteArrayList

इन वर्गों में इन विधियों का कोड लगभग एक से एक दोहराया जाता है। कई अनुप्रयोगों और चौखटे भी एक ही समस्या के लिए अपने समाधान प्रदान करते हैं:

• org.hibernate.bytecode.enhance.internal.tracker.SimpleFieldTracker
• com.intellij.util.ArrayUtil
• com.intellij.util.ArrayUtilRt
• org.springframework.oxm.jibx.JibxMarshaller

नतीजतन, हमारे पास आवारा कोड है जिसे संकलित करने की आवश्यकता है (कभी-कभी कभी-कभी कई बार), जो ReserverCodeCache में जगह लेता है, जिसे परीक्षण करने की आवश्यकता होती है, और जो बस लगभग कोई बदलाव के साथ कक्षा से कक्षा तक भटकता है।

डेवलपर्स, बदले में, कुछ लिखने का बहुत शौक रखते हैं

 int i = Arrays.asList(array).indexOf(obj); //  boolean contains = Arrays.asList(array).contains(obj); //    boolean contains = Arrays.stream(names).anyMatch(nm -> nm.equals(name)); 

मैं जेडीके में सामान्यीकृत उपयोगिता विधियों को लागू करना चाहता हूं, और उन्हें हर जगह उपयोग करना चाहिए, जैसा कि सुझाव दिया गया है । पैच दो पेनी के रूप में सरल है:

1) List.indexOf() और List.lastIndexOf() का कार्यान्वयन java.util.Arrays
2) इसके बजाय, Arrays.indexOf() और Arrays.lastIndexOf() क्रमशः कहलाते हैं

ऐसा लगता है कि क्या गलत हो सकता है? इस दृष्टिकोण से लाभ स्पष्ट प्रतीत होता है। लेकिन लेख विफलताओं के बारे में है, इसलिए सोचें कि क्या गलत हो सकता है।

- जिम्मेदार कौन?
- जिम्मेदार विशेषज्ञ मार्टिन बुचोलज़ और पॉल सैंडोज़

पत्राचार: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/051968.html

इस कल्पित कहानी का नैतिक यह है: आपके सरल पैच को समीक्षा के लिए केवल इसलिए मार दिया जा सकता है क्योंकि वे इसमें कोई विशेष मूल्य नहीं देखेंगे। ठीक है, हाँ, डुप्लिकेट कोड है, लेकिन यह किसी को परेशान नहीं करता है, इसलिए इसे लाइव करें।

ArrayList के लिए सुधार? मेरे पास है

इंजन से साइकिल पैच मेरा नहीं है, मैं आपको सोचने के लिए इसे पोस्ट करूंगा। इस प्रस्ताव को यहां आवाज दी गई थी, और यह बहुत आकर्षक लग रहा है। अपने लिए देखें:

नग्न आंखों के साथ, प्रस्ताव बहुत, बहुत तार्किक है। आप एक साधारण बेंचमार्क का उपयोग करके प्रदर्शन को माप सकते हैं:

 @State(Scope.Benchmark) public class ArrayListBenchmark { @State(Scope.Benchmark) public static class Data { @Param({"10", "100", "1000", "10000"}) public int size; ArrayList<Integer> arrayRandom = new ArrayList<Integer>(size); @Setup(Level.Invocation) public void initArrayList() { Random rand = new Random(); rand.setSeed(System.currentTimeMillis()); // Populate the ArrayList with size-5 elements for (int i = 0; i < size - 5; i++) { Integer r = rand.nextInt() % 256; arrayRandom.add(r); } } } @Benchmark public ArrayList construct_new_array_list(Data d) { ArrayList al = new ArrayList(d.arrayRandom); // once a new ArrayList is created add a new element al.add(new Integer(900)); return al; } } 

परिणाम:

 Benchmark (size) Mode Cnt Score Error Units  construct_new_array_list 10 thrpt 25 388.212 ± 23.110 ops/s construct_new_array_list 100 thrpt 25 90.208 ± 7.995 ops/s construct_new_array_list 1000 thrpt 25 23.289 ± 1.687 ops/s construct_new_array_list 10000 thrpt 25 7.659 ± 0.560 ops/s  construct_new_array_list 10 thrpt 25 562.678 ± 37.370 ops/s construct_new_array_list 100 thrpt 25 119.791 ± 13.232 ops/s construct_new_array_list 1000 thrpt 25 33.811 ± 3.812 ops/s construct_new_array_list 10000 thrpt 25 10.889 ± 0.564 ops/s 

इस तरह के एक साधारण बदलाव के लिए बुरा नहीं है। मुख्य बात यह है कि कोई पकड़ नहीं है। ईमानदारी से एक सरणी बनाएं, ईमानदारी से डेटा की प्रतिलिपि बनाएँ और आकार के बारे में मत भूलना। अब उन्हें निश्चित रूप से पैच स्वीकार करना चाहिए!

कुछ भी नहीं है मुझे ArrayList से अलग करने, और एक लिंक की गई सूची में डेटा स्टोर करने के लिए मना करता हूं। फिर c instanceof ArrayList सच्चाई लौटाएगा, हम कॉपी क्षेत्र में पहुंच जाएंगे और सुरक्षित रूप से गिर जाएंगे।

इस कल्पित कहानी का नैतिक यह है: व्यवहार में संभावित परिवर्तन विफलता का कारण हो सकता है। दूसरे शब्दों में, किसी को भी सबसे बेतुके बदलाव की संभावना को ध्यान में रखना चाहिए, अगर भाषा के माध्यम से इसकी अनुमति है। और हाँ, यह काम कर सकता था यदि ArrayList ने शुरू से ही final घोषित किया था।

विशिष्टता फिर से

अपने आवेदन को डीबग करते समय, मैं गलती से स्प्रिंग के चक्कर में पड़ गया और निम्नलिखित कोड पाया:

 //      paramTypes for (Constructor<?> candidate : candidates) { Class<?>[] paramTypes = candidate.getParameterTypes(); if (constructorToUse != null && argsToUse != null && argsToUse.length > paramTypes.length) { // Already found greedy constructor that can be satisfied -> // do not look any further, there are only less greedy constructors left. break; } if (paramTypes.length < minNrOfArgs) { continue; } 

सौभाग्य से, java.lang.reflect.Constructor.getParameterTypes() अंदर जाकर java.lang.reflect.Constructor.getParameterTypes() मैंने कोड को थोड़ा कम स्क्रॉल किया और एक सुंदर पाया:

 @Override public Class<?>[] getParameterTypes() { return parameterTypes.clone(); } /** * {@inheritDoc} * @since 1.8 */ public int getParameterCount() { return parameterTypes.length; } 

आप देखिए, हां? अगर हमें कंस्ट्रक्टर / विधि तर्कों की संख्या का पता लगाना है, तो बस java.lang.reflect.Method.getParameterCount() कॉल करें और ऐरे को कॉपी किए बिना करें। जांच करें कि क्या खेल सरलतम मामले में मोमबत्ती के लायक है, जिसमें विधि का कोई पैरामीटर नहीं है:

 @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class MethodToStringBenchmark { private Method method; @Setup public void setup() throws Exception { method = getClass().getMethod("toString"); } @Benchmark public int getParameterCount() { return method.getParameterCount(); } @Benchmark public int getParameterTypes() { return method.getParameterTypes().length; } } 

मेरी मशीन पर और JDK 11 के साथ यह इस तरह निकलता है:

 Benchmark Mode Cnt Score Error Units getParameterCount avgt 25 2,528 ± 0,085 ns/op getParameterCount:·gc.alloc.rate avgt 25 ≈ 10⁻⁴ MB/sec getParameterCount:·gc.alloc.rate.norm avgt 25 ≈ 10⁻⁷ B/op getParameterCount:·gc.count avgt 25 ≈ 0 counts getParameterTypes avgt 25 7,299 ± 0,410 ns/op getParameterTypes:·gc.alloc.rate avgt 25 1999,454 ± 89,929 MB/sec getParameterTypes:·gc.alloc.rate.norm avgt 25 16,000 ± 0,001 B/op getParameterTypes:·gc.churn.G1_Eden_Space avgt 25 2003,360 ± 91,537 MB/sec getParameterTypes:·gc.churn.G1_Eden_Space.norm avgt 25 16,030 ± 0,045 B/op getParameterTypes:·gc.churn.G1_Old_Gen avgt 25 0,004 ± 0,001 MB/sec getParameterTypes:·gc.churn.G1_Old_Gen.norm avgt 25 ≈ 10⁻⁵ B/op getParameterTypes:·gc.count avgt 25 2380,000 counts getParameterTypes:·gc.time avgt 25 1325,000 ms 

हम इसके बारे में क्या कर सकते हैं? हम Method.getParameterTypes().length के उपयोग की खोज कर सकते हैं Method.getParameterTypes().length JDK में Method.getParameterTypes().length (कम से कम java.base ) और इसे प्रतिस्थापित करें जहां यह समझ में आता है:

java.lang.invoke.MethodHandleProxies

java.util.concurrent.ForkJoinTask

java.lang.reflect.Executable

sun.reflect.annotation.AnnotationType

पैच को एक कवर लेटर के साथ भेजा गया था।

अचानक, यह पता चला कि कई वर्षों से एक समान कार्य किया गया है , और यहां तक ​​कि इसके लिए परिवर्तन भी तैयार किए गए हैं । इस तरह के साधारण बदलावों के लिए टिप्पणियों ने काफी अच्छा प्रदर्शन बढ़ाया। हालाँकि, वे और मेरे पैच दोनों अब तक साफ हैं और गतिहीन हैं। क्यों? शायद इसलिए कि डेवलपर्स बहुत अधिक आवश्यक चीजों में व्यस्त हैं और वे मूर्खता से इस पर अपना हाथ नहीं बढ़ाते हैं।

इस कल्पित कहानी का नैतिक यह है: श्रमिकों की कमी के कारण आपके सरल परिवर्तन स्थिर हो सकते हैं।

लेकिन यह अंत नहीं है! अन्य परियोजनाओं में वर्णित प्रतिस्थापन की तर्कसंगतता की चर्चा के दौरान, अधिक अनुभवी कॉमरेडों ने एक काउंटर प्रस्ताव सामने रखा: शायद आपको अपने हाथों से Method.getParameterTypes().length -> Method.getParameterCount() रिप्लेसमेंट नहीं करना चाहिए, लेकिन इसे कंपाइलर को सौंप दें। क्या यह संभव है और क्या यह "कानूनी" होगा?

आइए परीक्षण का उपयोग करके जांचने का प्रयास करें:

 @Test void arrayClone() { final Object[] objects = new Object[3]; objects[0] = "azaza"; objects[1] = 365; objects[2] = 9876L; final Object[] clone = objects.clone(); assertEquals(objects.length, clone.length); assertSame(objects[0], clone[0]); assertSame(objects[1], clone[1]); assertSame(objects[2], clone[2]); } 

जो गुजरता है, और जो दर्शाता है कि यदि क्लोन सरणी गुंजाइश नहीं छोड़ती है, तो इसे हटाया जा सकता है, क्योंकि इसकी कोशिकाओं या length क्षेत्र से किसी भी तत्व तक length मूल से प्राप्त की जा सकती है।

क्या जेडीके ऐसा कर सकती है? हम जाँच करते हैं:

 @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class ArrayAllocationEliminationBenchmark { private int length = 10; @Benchmark public int baseline() { return new int[length].length; } @Benchmark public int baselineClone() { return new int[length].clone().length; } } 

JDK 13 के लिए आउटपुट:

 Benchmark Mode Cnt Score Error Units baseline avgt 50 6,135 ± 0,140 ns/op baseline:·gc.alloc.rate.norm avgt 50 56,000 ± 0,001 B/op clone avgt 50 18,359 ± 0,619 ns/op clone:·gc.alloc.rate.norm avgt 50 112,000 ± 0,001 B/op 

यह पता चला है कि ओपनजेडक new int[length] फेंकना नहीं जानता है, ग्रिल के विपरीत, हेह:

 Benchmark Mode Cnt Score Error Units baseline avgt 25 2,470 ± 0,156 ns/op baseline:·gc.alloc.rate.norm avgt 25 0,005 ± 0,008 B/op lone avgt 25 13,086 ± 1,059 ns/op lone:·gc.alloc.rate.norm avgt 25 112,113 ± 0,115 B/op 

यह पता चला है कि आप ओपनजेक ऑप्टिमाइज़िंग कंपाइलर को थोड़ा मोड़ सकते हैं ताकि यह कर सके कि ग्रिल क्या कर सकता है। चूंकि वीएम कोड में न केवल हर कोई सकारात्मक विज्ञापन प्राप्त कर सकता है और कुछ सार्थक फाइल कर सकता है, मैंने खुद को एक पत्र तक सीमित कर दिया, जिसमें मैंने अपनी टिप्पणियों को कहा था।

यह पता चला है, और कई सूक्ष्मताएं हैं। व्लादिमीर इवानोव इंगित करता है कि:

ध्यान में रखते हुए जावा सरणियों को बढ़ने / सिकोड़ने का कोई तरीका नहीं है,
"cloned_array.length => original_array.length" परिवर्तन सही है
चाहे क्लोन संस्करण बच गए या नहीं।

इसके अलावा, परिवर्तन पहले से ही है:

http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/opto/memnode.cpp#l2388

मैंने आपके द्वारा उल्लिखित बेंचमार्क पर ध्यान नहीं दिया है, लेकिन ऐसा लगता है
cloned_array.length पहुंच का कारण क्लोन क्लोन अभी भी नहीं है
वहाँ।

आपके अन्य विचारों के संबंध में, क्लोन किए गए उदाहरण से पहुंच को पुनर्निर्देशित करता है
मूल समस्याग्रस्त है (सामान्य स्थिति में) क्योंकि संकलक को साबित करना होता है
दोनों संस्करणों में कोई बदलाव नहीं किया गया था और अनुक्रमित पहुंच इसे भी बनाते हैं
कठिन। और सेफपाइंट के कारण समस्याएँ होती हैं (रीमैट्रीकरण के लिए)।

लेकिन मैं मानता हूं कि कम से कम मामलों को कवर करना अच्छा होगा
रक्षात्मक नकल।

यही है, क्लोन को पीटना संभव प्रतीत होता है, और विशेष रूप से मुश्किल नहीं है। लेकिन रूपांतरण के साथ

 int len = new int[arrayLength].length; 

->

 int len = arrayLength; 

कठिनाइयाँ उत्पन्न होती हैं:

हम उन सरणी आवंटन को समाप्त नहीं करते हैं जिनकी कोई ज्ञात लंबाई नहीं है
क्योंकि वे एक NegativeArraySize अपवाद का कारण हो सकता है। इस मामले में हम
यह साबित करने में सक्षम होना चाहिए कि लंबाई सकारात्मक है।

वैसे भी - मेरे पास लगभग समाप्त पैच है जो अप्रयुक्त सरणी को प्रतिस्थापित करता है
एक उचित गार्ड के साथ आवंटन।

दूसरे शब्दों में, आप सिर्फ एक सरणी के निर्माण को नहीं ले सकते हैं और फेंक नहीं सकते हैं, क्योंकि विनिर्देश के अनुसार , निष्पादन को एक NegativeArraySizeException को फेंकना होगा NegativeArraySizeException और इसके बारे में हम कुछ भी नहीं कर सकते हैं:

 @Test void arrayWithNwgativeSize() { int length = 0; try { int newLen = -3; length = new Object[newLen].length; //  new Object[newLen]  fail(); } catch (NegativeArraySizeException e) { assert length == 0; } } 

ग्रिल क्यों सक्षम था? मुझे लगता है कि इसका कारण यह है कि ऊपर दिए गए बेंचमार्क में length फ़ील्ड का मान स्थिर और हमेशा 10 के बराबर था, जिसने प्रोफाइलर को यह निष्कर्ष निकालने की अनुमति दी कि नकारात्मक मूल्य की जांच करना आवश्यक नहीं है, जिसका अर्थ है कि इसे सरणी के निर्माण के साथ ही हटाया जा सकता है। अगर मैंने कोई गलती की है तो टिप्पणियों में सुधार करें।

आज के लिए बस इतना ही है :) टिप्पणियों में अपने उदाहरण जोड़ें, हम समझेंगे।