इसमें सुधार करके प्रदर्शन को कैसे नीचा दिखाया जाए

हम सबसे अच्छा चाहते थे, लेकिन यह हमेशा की तरह निकला।
विक्टर चेर्नोमिरिन,
रूसी राजनेता

ज़िन्दगी में कई बार ऐसा होता है जब आप सब कुछ सही करते नज़र आते हैं, लेकिन कुछ गलत हो जाता है।
यह कहानी ऐसे ही एक मामले के बारे में है।

एक बार मैंने इस कोड को देखा और इसे गति देने के बारे में सोचा:

public String appendBounds(Data data) { int beginIndex = data.beginIndex; int endIndex = data.endIndex; return new StringBuilder() .append('L') .append(data.str, beginIndex, endIndex) .append(';') .toString(); } 

सबसे पहले, मैं चर की कुल लंबाई की गणना करना शुरू कर रहा हूं चर beginIndex का उपयोग करके beginIndex और endIndex (साथ ही इस तथ्य के साथ कि छंटनी की गई स्ट्रिंग के अलावा, स्ट्रींगबुइट में 2 और पात्रों को जोड़ा जाएगा), और आवश्यक मान के आकार का चयन करने के लिए इस मूल्य को तुरंत स्ट्रिंग निर्माता के पास दें। । यह विचार मुझे बहुत स्पष्ट लगा, इसलिए मैंने कुछ और करने की कोशिश की। तथ्य यह है कि इस कोड को "आइडिया" द्वारा हाइलाइट नहीं किया गया था, जिसने मुझे सही विचार के लिए प्रेरित किया, हालांकि यह चतुर लड़की आमतौर पर स्ट्रिंग स्ट्रिंग के स्थान पर शॉर्ट स्ट्रिंग को बदलने का सुझाव देती है StringBuilder::append स्ट्रिंग्स के अलावा के साथ StringBuilder::append करें, जो छोटा और पढ़ने में आसान है।

इस सरलीकरण के लिए एक बाधा StringBuilder.append(CharSequence, int, int) विधि का उपयोग है। यह देखते हुए कि data.str फ़ील्ड एक स्ट्रिंग है, String.substring(beginIndex, endIndex) का उपयोग करके String.substring(beginIndex, endIndex) आप इसमें से एक विकल्प चुन सकते हैं और इसे StringBuilder.append(String) को पास कर सकते हैं।

रूपांतरण के बाद कोड:

 public String appendBounds(Data data) { int beginIndex = data.beginIndex; int endIndex = data.endIndex; String subString = data.str.substring(beginIndex, endIndex); return new StringBuilder() .append('L') .append(subString) .append(';') .toString(); } 

और अब आइडिया एक सरलीकरण प्रदान करता है:

 public String appendBounds(Data data) { int beginIndex = data.beginIndex; int endIndex = data.endIndex; return 'L' + data.str.substring(beginIndex, endIndex) + ';'; } 

हालाँकि, इस मामले में हमारा लक्ष्य उत्पादकता के रूप में इतनी पठनीयता नहीं है। दोनों तरीकों की तुलना करें:

 @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class StringBuilderAppendBenchmark { @Benchmark public String appendSubString(Data data) { String latinStr = data.latinStr; String nonLatinStr = data.nonLatinStr; int beginIndex = data.beginIndex; int endIndex = data.endIndex; String substring = data.nonLatin ? nonLatinStr.substring(beginIndex, endIndex) : latinStr.substring(beginIndex, endIndex); return new StringBuilder() .append('L') .append(substring) .append(';') .toString(); } @Benchmark public String appendBounds(Data data) { String latinStr = data.latinStr; String nonLatinStr = data.nonLatinStr; int beginIndex = data.beginIndex; int endIndex = data.endIndex; String appended = data.nonLatin ? nonLatinStr : latinStr; return new StringBuilder() .append('L') .append(appended, beginIndex, endIndex) .append(';') .toString(); } @State(Scope.Thread) public static class Data { String latinStr; String nonLatinStr; @Param({"true", "false"}) boolean nonLatin; @Param({"5", "10", "50", "100", "500", "1000"}) private int length; private int beginIndex; private int endIndex; private ThreadLocalRandom random = ThreadLocalRandom.current(); @Setup public void setup() { latinStr = randomString("abcdefghijklmnopqrstuvwxyz"); nonLatinStr = randomString(""); beginIndex = 1; endIndex = length + 1; } private String randomString(String alphabet) { char[] chars = alphabet.toCharArray(); StringBuilder sb = new StringBuilder(length + 2); for (int i = 0; i < length + 2; i++) { char c = chars[random.nextInt(chars.length)]; sb.append(c); } return sb.toString(); } } } 

बेंचमार्क दो पेनी के समान सरल है: एक यादृच्छिक स्ट्रिंग को स्ट्रिंगबर्ब्यूल में जोड़ा जाता है, जिसका आकार length क्षेत्र द्वारा निर्धारित किया जाता है, और जब से यार्ड 2019 है, तो आपको इसे एक स्ट्रिंग के रूप में जांचना होगा जिसमें मुख्य लैटिन वर्णमाला (तथाकथित संपीड़ित लाइन), जिसमें प्रत्येक चरित्र के अक्षर होते हैं। 1 बाइट से मेल खाती है), और गैर-लैटिन वर्णों के साथ एक स्ट्रिंग (प्रत्येक चरित्र 2 बाइट्स द्वारा दर्शाया गया है)।

एक सरसरी परीक्षा पर, appendSubString विधि हमें धीमी appendSubString है, क्योंकि appendBounds विधि के साथ चिपके हुए डेटा की मात्रा को जोड़ा जाता है, हालांकि, appendSubString विधि में एक appendSubString एक स्पष्ट निर्माण भी है, अर्थात्, एक नई वस्तु के लिए मेमोरी आवंटित करना और data.latinStr से सामग्री की प्रतिलिपि बनाना। / data.nonLatinStr ।

सभी अधिक आश्चर्यजनक (लेकिन केवल पहली नज़र में) एक घरेलू मशीन (इंटेल कोर i5-4690, 3.50 GHz) पर JDK11 का उपयोग करके मेरे द्वारा किए गए माप के परिणाम प्रतीत होते हैं:

 Benchmark nonLatin length Score Error Units appendBounds true 5 44,6 ± 0,4 ns/op appendBounds true 10 45,7 ± 0,7 ns/op appendBounds true 50 129,0 ± 0,5 ns/op appendBounds true 100 218,7 ± 0,8 ns/op appendBounds true 500 907,1 ± 5,5 ns/op appendBounds true 1000 1626,4 ± 13,0 ns/op appendSubString true 5 28,6 ± 0,2 ns/op appendSubString true 10 30,8 ± 0,2 ns/op appendSubString true 50 65,6 ± 0,4 ns/op appendSubString true 100 106,6 ± 0,6 ns/op appendSubString true 500 430,1 ± 2,4 ns/op appendSubString true 1000 839,1 ± 8,6 ns/op appendBounds:·gc.alloc.rate.norm true 5 184,0 ± 0,0 B/op appendBounds:·gc.alloc.rate.norm true 10 200,0 ± 0,0 B/op appendBounds:·gc.alloc.rate.norm true 50 688,0 ± 0,0 B/op appendBounds:·gc.alloc.rate.norm true 100 1192,0 ± 0,0 B/op appendBounds:·gc.alloc.rate.norm true 500 5192,0 ± 0,0 B/op appendBounds:·gc.alloc.rate.norm true 1000 10200,0 ± 0,0 B/op appendSubString:·gc.alloc.rate.norm true 5 136,0 ± 0,0 B/op appendSubString:·gc.alloc.rate.norm true 10 160,0 ± 0,0 B/op appendSubString:·gc.alloc.rate.norm true 50 360,0 ± 0,0 B/op appendSubString:·gc.alloc.rate.norm true 100 608,0 ± 0,0 B/op appendSubString:·gc.alloc.rate.norm true 500 2608,0 ± 0,0 B/op appendSubString:·gc.alloc.rate.norm true 1000 5104,0 ± 0,0 B/op appendBounds false 5 20,8 ± 0,1 ns/op appendBounds false 10 24,0 ± 0,2 ns/op appendBounds false 50 66,4 ± 0,4 ns/op appendBounds false 100 111,0 ± 0,8 ns/op appendBounds false 500 419,2 ± 2,7 ns/op appendBounds false 1000 840,4 ± 7,8 ns/op appendSubString false 5 25,3 ± 0,3 ns/op appendSubString false 10 25,7 ± 0,2 ns/op appendSubString false 50 36,0 ± 0,1 ns/op appendSubString false 100 52,8 ± 0,4 ns/op appendSubString false 500 206,1 ± 6,1 ns/op appendSubString false 1000 388,1 ± 1,6 ns/op appendBounds:·gc.alloc.rate.norm false 5 80,0 ± 0,0 B/op appendBounds:·gc.alloc.rate.norm false 10 88,0 ± 0,0 B/op appendBounds:·gc.alloc.rate.norm false 50 320,0 ± 0,0 B/op appendBounds:·gc.alloc.rate.norm false 100 544,0 ± 0,0 B/op appendBounds:·gc.alloc.rate.norm false 500 2144,0 ± 0,0 B/op appendBounds:·gc.alloc.rate.norm false 1000 4152,0 ± 0,0 B/op appendSubString:·gc.alloc.rate.norm false 5 96,0 ± 0,0 B/op appendSubString:·gc.alloc.rate.norm false 10 112,0 ± 0,0 B/op appendSubString:·gc.alloc.rate.norm false 50 192,0 ± 0,0 B/op appendSubString:·gc.alloc.rate.norm false 100 288,0 ± 0,0 B/op appendSubString:·gc.alloc.rate.norm false 500 1088,0 ± 0,0 B/op appendSubString:·gc.alloc.rate.norm false 1000 2088,0 ± 0,0 B/op 

हमारी धारणा का खंडन करते हुए, अधिकांश मामलों में (नॉन-लैटिन स्ट्रिंग्स के लिए हमेशा सहित) appendSubString विधि तेजी से और कम ग्लूटोनस (भले ही String::substring एक नई वस्तु देता है) निकला। यह कैसे हुआ?

मैं किताब में देखता हूं, मुझे एक अंजीर दिखाई देती है

StringBuilder स्रोत कोड का अध्ययन करने से गोपनीयता StringBuilder पर्दा StringBuilder मदद मिलेगी। दोनों उपयोग की गई विधियाँ AbstractStringBuilder के समान तरीकों से कॉल पास करती हैं:

 public final class StringBuilder extends AbstractStringBuilder implements java.io.Serializable, Comparable<StringBuilder>, CharSequence { @Override public StringBuilder append(String str) { super.append(str); return this; } @Override public StringBuilder append(CharSequence s, int start, int end) { super.append(s, start, end); return this; } } 

AbstractStringBuilder.append(String) :

 public AbstractStringBuilder append(String str) { if (str == null) { return appendNull(); } int len = str.length(); ensureCapacityInternal(count + len); putStringAt(count, str); count += len; return this; } private final void putStringAt(int index, String str) { if (getCoder() != str.coder()) { inflate(); } str.getBytes(value, index, coder); } 

यहाँ क्या दिलचस्प है? AbstractStringBuilder::inflate नाम के रूप में AbstractStringBuilder::inflate , असमान तार का संयोजन करते समय AbstractStringBuilder.value सरणी का विस्तार करता है। डेटा को String::getBytes में String::getBytes गया है:

 void getBytes(byte[] dst, int dstBegin, byte coder) { if (coder() == coder) { System.arraycopy(value, 0, dst, dstBegin << coder, value.length); } else { // this.coder == LATIN && coder == UTF16 StringLatin1.inflate(value, 0, dst, dstBegin, value.length); } } 

क्या महत्वपूर्ण है? यदि तार समरूप होते हैं, तो आंतरिक System::arraycopy का उपयोग डेटा को स्थानांतरित करने के लिए किया जाता है, अन्यथा StringLatin1::inflate जाता है, जो प्रतिनिधिमंडल के माध्यम से हमें StringUTF16::inflate ओर ले जाता है:

 // inflatedCopy byte[] -> byte[] @HotSpotIntrinsicCandidate public static void inflate(byte[] src, int srcOff, byte[] dst, int dstOff, int len) { // We need a range check here because 'putChar' has no checks checkBoundsOffCount(dstOff, len, dst); for (int i = 0; i < len; i++) { putChar(dst, dstOff++, src[srcOff++] & 0xff); } } @HotSpotIntrinsicCandidate static void putChar(byte[] val, int index, int c) { assert index >= 0 && index < length(val) : "Trusted caller missed bounds check"; index <<= 1; val[index++] = (byte)(c >> HI_BYTE_SHIFT); val[index] = (byte)(c >> LO_BYTE_SHIFT); } 

इस प्रकार, यदि पंक्तियाँ सजातीय हैं, तो प्लेटफ़ॉर्म-आश्रित विधि System::arraycopy को डेटा स्थानांतरित करने के लिए उपयोग किया जाता है, अन्यथा एक लूप (आंतरिक भी) का उपयोग किया जाता है। इसका मतलब यह है कि जब दो लाइनों को ग्लूइंग करते हैं, जहां सभी वर्ण मुख्य लैटिन वर्णमाला के सेट में होते हैं (दूसरे शब्दों में, 1 बाइट में फिट होते हैं), तो प्रदर्शन विषम लाइनों की तुलना में बहुत बेहतर होना चाहिए। बेंचमार्क इसकी पुष्टि करता है ( nonLatin = false लिए आउटपुट देखें)।

अब AbstractStringBuilder.append(CharSequence, int, int) विधि AbstractStringBuilder.append(CharSequence, int, int) :

 @Override public AbstractStringBuilder append(CharSequence s, int start, int end) { if (s == null) { s = "null"; } checkRange(start, end, s.length()); int len = end - start; ensureCapacityInternal(count + len); appendChars(s, start, end); return this; } private final void appendChars(CharSequence s, int off, int end) { if (isLatin1()) { byte[] val = this.value; for (int i = off, j = count; i < end; i++) { char c = s.charAt(i); if (StringLatin1.canEncode(c)) { val[j++] = (byte)c; } else { count = j; inflate(); StringUTF16.putCharsSB(this.value, j, s, i, end); count += end - i; return; } } } else { StringUTF16.putCharsSB(this.value, count, s, off, end); } count += end - off; } 

यहां, दृष्टिकोण पिछले उदाहरण में एक के समान है: सजातीय तारों के लिए, एक सरल तंत्र का उपयोग किया जाता है (यहां, एक पाश में प्रतिलिपि साइन इन करें), विषम तारों के लिए हम StringUTF16 उपयोग StringUTF16 , हालांकि, ध्यान दें कि StringUTF16::putCharsSB आंतरिक नहीं कहा गया StringUTF16::putCharsSB ।

 public static void putCharsSB(byte[] val, int index, CharSequence s, int off, int end) { checkBoundsBeginEnd(index, index + end - off, val); for (int i = off; i < end; i++) { putChar(val, index++, s.charAt(i)); } } 

तो, दोनों तरीकों की आंतरिक संरचना और उनके अलग-अलग प्रदर्शन का कारण कमोबेश हमारे लिए स्पष्ट है। सवाल स्वाभाविक रूप से उठता है - आगे प्राप्त ज्ञान के साथ क्या करना है? एक साथ कई विकल्प हैं:

1) इसे ध्यान में रखें और जब यह एक संदिग्ध कोड का पता लगाता है, तो इसे हाथ से बदल दें
2) टैगिर के पास जाओ और उसे एक चेक दायर करने के लिए कहें जो हमारे बजाय काम करेगा
3) जेडीके में बदलाव करें ताकि कोड बिल्कुल भी न बदले।

बेशक, हम तीसरे के साथ शुरू करते हैं। मौका लेने के लिए तैयार हैं?

Deeps में नीचे

हम प्रशिक्षण देंगे बिल्लियों पर ग्यारहवें जावा के स्रोत कोड पर, आप यहां डाउनलोड कर सकते हैं ।

सुधार करने का सबसे सरल और स्पष्ट तरीका है कि पहले से ही AbstractStringBuilder.append(CharSequence, int, int) विधि के अंदर एक विकल्प का चयन करें:

 //  public AbstractStringBuilder append(CharSequence s, int start, int end) { if (s == null) { s = "null"; } checkRange(start, end, s.length()); int len = end - start; ensureCapacityInternal(count + len); appendChars(s, start, end); return this; } //  public AbstractStringBuilder append(CharSequence s, int start, int end) { if (s == null) { s = "null"; } checkRange(start, end, s.length()); return append(s.subSequence(start, end).toString()); } 

अब आपको JDK बनाने की जरूरत है, परीक्षण चलाएं और उस पर StringBuilderAppendBenchmark::appendBounds बेंचमार्क StringBuilderAppendBenchmark::appendBounds , जिसके परिणामों की तुलना मूल JDK पर एक ही बेंचमार्क के परिणामों के साथ करने की आवश्यकता है:

 #   before      JDK, # after -   Benchmark nonLatin length before after Units avgt true 5 44,6 64,4 ns/op avgt true 10 45,7 66,3 ns/op avgt true 50 129,0 168,9 ns/op avgt true 100 218,7 281,9 ns/op avgt true 500 907,1 1116,2 ns/op avgt true 1000 1626,4 2002,5 ns/op gc.alloc.rate.norm true 5 184,0 264,0 B/op gc.alloc.rate.norm true 10 200,0 296,0 B/op gc.alloc.rate.norm true 50 688,0 904,0 B/op gc.alloc.rate.norm true 100 1192,0 1552,0 B/op gc.alloc.rate.norm true 500 5192,0 6752,0 B/op gc.alloc.rate.norm true 1000 10200,0 13256,0 B/op avgt false 5 20,8 38,0 ns/op avgt false 10 24,0 37,8 ns/op avgt false 50 66,4 82,9 ns/op avgt false 100 111,0 138,8 ns/op avgt false 500 419,2 531,9 ns/op avgt false 1000 840,4 1002,7 ns/op gc.alloc.rate.norm false 5 80,0 152,0 B/op gc.alloc.rate.norm false 10 88,0 168,0 B/op gc.alloc.rate.norm false 50 320,0 440,0 B/op gc.alloc.rate.norm false 100 544,0 688,0 B/op gc.alloc.rate.norm false 500 2144,0 2688,0 B/op gc.alloc.rate.norm false 1000 4152,0 5192,0 B/op 

क्या कहते हैं, अचानक! सुधार न केवल हुआ, बल्कि गिरावट भी हुई। लानत है, लेकिन कैसे?

तथ्य यह है कि बहुत शुरुआत में, StringBuilder::append विधि के विवरण में StringBuilder::append मैंने एक छोटी, लेकिन गंभीर रूप से महत्वपूर्ण चूक की। विधि इस तरह वर्णित थी:

 public final class StringBuilder { @Override public StringBuilder append(String str) { super.append(str); return this; } } 

और यहाँ इसका पूरा दृश्य है:

 public final class StringBuilder { @Override @HotSpotIntrinsicCandidate public StringBuilder append(String str) { super.append(str); return this; } } 

जावा कोड जिसे हमने ऊपर जांचा, सी 2 स्तर पर गर्म और संकलित किया गया, इससे कोई फर्क नहीं पड़ता, क्योंकि इसे निष्पादित नहीं किया गया है, लेकिन आंतरिक। यह async-profiler का उपयोग करके प्रोफ़ाइल को हटाकर साबित करना आसान है। इसके बाद, प्रोफ़ाइल को length = 1000 और nonLatin = true - nonLatin = true लिए हटा दिया जाता nonLatin = true :

 #   `appendSubString`, JDK    ns percent samples top ---------- ------- ------- --- 19096340914 43.57% 1897673 jbyte_disjoint_arraycopy <--------- 13500185356 30.80% 1343343 jshort_disjoint_arraycopy <--------- 4124818581 9.41% 409533 java.lang.String.<init> #   2177311938 4.97% 216375 java.lang.StringUTF16.compress #   1557269661 3.55% 154253 java.util.Arrays.copyOfRange #   349344451 0.80% 34823 appendSubString_avgt_jmhStub 279803769 0.64% 27862 java.lang.StringUTF16.newString 274388920 0.63% 27312 org.openjdk.jmh.infra.Blackhole.consume 160962540 0.37% 15946 SpinPause 122418222 0.28% 11795 __memset_avx2 

StringBuilder (और AbstractStringBuilder ) का कोड यहां भी गंध नहीं करता है, प्रोफ़ाइल के लगभग 3/4 पर एक आंतरिक द्वारा कब्जा कर लिया जाता है। मैं हमारे "बेहतर" StringBuilder.append(CharSequence, int, int) के प्रोफाइल में एक ही तस्वीर के बारे में निरीक्षण करना चाहूंगा।

वास्तव में, हमारे पास यह है:

  ns percent samples top ---------- ------- ------- --- 19071221451 43.78% 1897827 jbyte_disjoint_arraycopy 6409223440 14.71% 638348 jlong_disjoint_arraycopy 3933622128 9.03% 387403 java.lang.StringUTF16.newBytesFor 2067248311 4.75% 204193 java.lang.AbstractStringBuilder.ensureCapacityInternal 1929218737 4.43% 194751 java.lang.StringUTF16.compress 1678321343 3.85% 166458 java.util.Arrays.copyOfRange 1621470408 3.72% 160849 java.lang.String.checkIndex 969180099 2.22% 96018 java.util.Arrays.copyOf 581600786 1.34% 57818 java.lang.AbstractStringBuilder.<init> 417818533 0.96% 41611 appendBounds_jmhTest 406565329 0.93% 40479 java.lang.String.<init> 340972882 0.78% 33727 java.lang.AbstractStringBuilder.append 299895915 0.69% 29982 java.lang.StringBuilder.toString 183885595 0.42% 18136 SpinPause 168666033 0.39% 16755 org.openjdk.jmh.infra.Blackhole.consume 

आप कहेंगे: "वे यहाँ हैं, आंतरिक, बहुत ऊपर!" वास्तव में, केवल ये एक ही आंतरिक नहीं हैं (ऊपर से दूसरे के नाम की तुलना करें)। याद:

 public final class StringBuilder { @Override @HotSpotIntrinsicCandidate public StringBuilder append(String str) { super.append(str); return this; } } 

यहाँ आंतरिक कॉल StringBuilder.append(String) को बदल देता है, लेकिन हमारे पैच में यह कॉल नहीं है! जिसे AbstractStringBuilder.append(String) कहा जाता है। jbyte_disjoint_arraycopy कॉल जिसे हम jbyte_disjoint_arraycopy , वह StringLatin1::inflate लिए आंतरिक है, जिसे AbstractStringBuider::putStringAt कहा जाता है AbstractStringBuider::putStringAt माध्यम से String::getBytes । यही है, StringBuilder::append विपरीत StringBuilder::append न केवल प्लेटफ़ॉर्म-विशिष्ट, बल्कि जावा कोड भी संसाधित करता है,

असफलता के कारण को समझें, अन्यथा सफल होने का प्रयास करें। यह अनुमान लगाना आसान है कि हमें किसी तरह StringBuilder::append को संदर्भित करना होगा। आप पिछले पैच को फाड़कर और StringBuilder खुद बदलाव करके ऐसा कर सकते हैं:

 public final class StringBuilder { //  @Override public StringBuilder append(CharSequence s, int start, int end) { super.append(s, start, end); return this; } //  @Override public StringBuilder append(CharSequence s, int start, int end) { if (s == null) { s = "null"; } checkRange(start, end, s.length()); return this.append(s.subSequence(start, end).toString()); } } 

अब सब कुछ समझदारी से किया जाता है: आंतरिक StringBuilder :: परिशिष्ट कहा जाता है।
फिर से बनाएँ, चलाएं, तुलना करें:

 #   before      JDK, # after -   Benchmark nonLatin length before after Units avgt true 5 44,6 60,2 ns/op avgt true 10 45,7 59,1 ns/op avgt true 50 129,0 164,6 ns/op avgt true 100 218,7 276,2 ns/op avgt true 500 907,1 1088,8 ns/op avgt true 1000 1626,4 1959,4 ns/op gc.alloc.rate.norm true 5 184,0 264,0 B/op gc.alloc.rate.norm true 10 200,0 296,0 B/op gc.alloc.rate.norm true 50 688,0 904,0 B/op gc.alloc.rate.norm true 100 1192,0 1552,0 B/op gc.alloc.rate.norm true 500 5192,0 6752,0 B/op gc.alloc.rate.norm true 1000 10200,0 13256,0 B/op avgt false 5 20,8 37,9 ns/op avgt false 10 24,0 37,9 ns/op avgt false 50 66,4 80,9 ns/op avgt false 100 111,0 125,6 ns/op avgt false 500 419,2 483,6 ns/op avgt false 1000 840,4 893,8 ns/op gc.alloc.rate.norm false 5 80,0 152,0 B/op gc.alloc.rate.norm false 10 88,0 168,0 B/op gc.alloc.rate.norm false 50 320,0 440,0 B/op gc.alloc.rate.norm false 100 544,0 688,0 B/op gc.alloc.rate.norm false 500 2144,0 2688,0 B/op gc.alloc.rate.norm false 1000 4152,0 5187,2 B/op 

मैं वास्तव में बहुत दुखी हूं, लेकिन यह बेहतर नहीं हुआ। अब एक नया प्रोफ़ाइल:

  ns percent samples top ---------- ------- ------- --- 19614374885 44.12% 1953620 jbyte_disjoint_arraycopy 6645299702 14.95% 662146 jlong_disjoint_arraycopy 4065789919 9.15% 400167 java.lang.StringUTF16.newBytesFor 2374627822 5.34% 234746 java.lang.AbstractStringBuilder.ensureCapacityInternal 1837858014 4.13% 183822 java.lang.StringUTF16.compress 1472039604 3.31% 145956 java.util.Arrays.copyOfRange 1316397864 2.96% 130747 appendBounds_jmhTest 956823151 2.15% 94959 java.util.Arrays.copyOf 573091712 1.29% 56933 java.lang.AbstractStringBuilder.<init> 434454076 0.98% 43202 java.lang.String.<init> 368480388 0.83% 36439 java.lang.AbstractStringBuilder.append 304409057 0.68% 30442 java.lang.StringBuilder.toString 272437989 0.61% 26833 SpinPause 201051696 0.45% 19985 java.lang.StringBuilder.<init> 198934052 0.45% 19810 appendBounds_avgt_jmhStub 

थोड़ा बदल गया है। मेरे लिए, यह स्पष्ट नहीं है कि StringBuilder.append(String) भीतर से StringBuilder.append(String) तक StringBuilder.append(String) समय आंतरिक काम क्यों नहीं किया। एक संदेह है कि StringBuilder.append(String) पद्धति के शरीर को StringBuilder.append(CharSequence, int, int) के शरीर में चिपकाने से वीएम विधि कॉल के प्रसंस्करण में कुछ परिवर्तन होता है।

वैसे भी, यह फियास्को, भाई है। जेडीके को पैच करना संभव नहीं था, लेकिन हम अभी भी मैन्युअल रूप से प्रतिस्थापन कर सकते हैं जहां यह समझ में आता है।

निष्कर्ष:

• कुछ मामलों में जेडीके विधियों का कोड वास्तविक निष्पादन के लिए प्रासंगिक नहीं है, क्योंकि विधि के शरीर के बजाय एक आंतरिक निष्पादित किया जा सकता है, जो वीएम के आंतों में छिपा हुआ है।
• इसी तरह के तरीकों को पहचाना जा सकता है, विशेष रूप से, @HotSpotIntrinsicCandidate लेबल उन्हें इंगित करता है, हालांकि कुछ तरीकों को बिना किसी संकेत के आंतरिक रूप से @HotSpotIntrinsicCandidate जाता है, उदाहरण के लिए String::equals (और कई, कई अन्य )।
• पहले दो से जो निष्कर्ष निकलता है वह यह है कि जेडीके कोड कैसे काम करता है, इसके बारे में हमारी चर्चा वास्तविकता के विपरीत हो सकती है। C'est la vie

पुनश्च
एक और संभावित प्रतिस्थापन:

 StringBuilder sb = new StringBuilder(); sb.append(str, 0, endIndex); // --> StringBuilder sb = new StringBuilder(str.substring(o, endIndex)); 

पी पी एस
ओरेकल डेवलपर्स ठीक ही इंगित करते हैं

यह एक कोड पथ में पेश करने के बजाय मुझे अजीब और आश्चर्यजनक लगता है
sb.append (सीएस, इंट, इंट) जो स्मृति को आवंटित करता है ताकि आंतरिक रूप से प्राप्त किया जा सके
केवल कभी-कभी चीजें तेजी से चलती हैं। जैसा कि आपने देखा, प्रदर्शन
ट्रेडऑफ़ स्पष्ट नहीं हैं।

इसके बजाय, यदि हम sb.append (cs, int, int) को अनुकूलित करना चाहते हैं तो शायद हमें बस जाना चाहिए
आगे और करें, संभवतः आंतरिक रूप से जोड़कर या पुनर्व्यवस्थित करके।

प्रस्तावित समाधान StringBuilder.append(CharSequence, int, int) ।

→ कार्य
→ चर्चा

पी पी एस
दिलचस्प है, इस समय, जब कुछ लिखना पसंद है

 StringBuilder sb = new StringBuilder(); sb.append(str.substring(0, endIndex)); 

"आइडिया" से कोड को सरल बनाने का सुझाव मिलता है

 StringBuilder sb = new StringBuilder(); sb.append(s, 0, endIndex); 

यदि इस स्थान में प्रदर्शन आपके लिए बहुत महत्वपूर्ण नहीं है, तो संभवतः दूसरे, सरलीकृत संस्करण का उपयोग करना अधिक सही है। फिर भी, हम जो भी कोड लिखते हैं, उसका अधिकांश भाग हमारे कामरेड के लिए होता है, मशीनों के लिए नहीं।