वहाँ के बीच एक प्रदर्शन अंतर है i++और ++iअगर परिणामस्वरूप मूल्य नहीं किया जाता है?
जवाबों:
कार्यकारी सारांश: नहीं।
i++संभावित रूप से धीमा हो सकता है ++i, क्योंकि बाद में उपयोग के लिए पुराने मूल्य को i
सहेजने की आवश्यकता हो सकती है, लेकिन व्यवहार में सभी आधुनिक संकलक इसे दूर का अनुकूलन करेंगे।
हम इस फ़ंक्शन के लिए ++iऔर दोनों के साथ कोड को देखकर इसका प्रदर्शन कर सकते हैं i++।
$ cat i++.c
extern void g(int i);
void f()
{
int i;
for (i = 0; i < 100; i++)
g(i);
}
फ़ाइलें एक ही हैं, को छोड़कर ++iऔर i++:
$ diff i++.c ++i.c
6c6
< for (i = 0; i < 100; i++)
---
> for (i = 0; i < 100; ++i)
हम उन्हें संकलित करेंगे, और उत्पन्न कोडांतरक भी प्राप्त करेंगे:
$ gcc -c i++.c ++i.c
$ gcc -S i++.c ++i.c
और हम देख सकते हैं कि उत्पन्न वस्तु और कोडांतरक दोनों फाइलें समान हैं।
$ md5 i++.s ++i.s
MD5 (i++.s) = 90f620dda862cd0205cd5db1f2c8c06e
MD5 (++i.s) = 90f620dda862cd0205cd5db1f2c8c06e
$ md5 *.o
MD5 (++i.o) = dd3ef1408d3a9e4287facccec53f7d22
MD5 (i++.o) = dd3ef1408d3a9e4287facccec53f7d22
++iबजाय उपयोग करने के लिए अभी भी अच्छा अभ्यास है i++। वहाँ बिल्कुल कोई कारण नहीं है, और यदि आपका सॉफ़्टवेयर कभी एक टूलकिन से गुजरता है जो इसे अनुकूलित नहीं करता है तो आपका सॉफ़्टवेयर अधिक कुशल होगा। इसे टाइप करना उतना ही आसान है ++iजितना कि टाइप करना i++, ++iपहली जगह में इस्तेमाल न करना वास्तव में कोई बहाना नहीं है ।
से क्षमता आशय बनाम एंड्रयू कोएनिग द्वारा:
सबसे पहले, यह स्पष्ट है कि कम से कम जहां पूर्णांक चर का संबंध है,
++iसे अधिक कुशल हैi++।
तथा :
तो सवाल यह होना चाहिए कि इन दोनों में से कौन सा ऑपरेशन तेज नहीं है, यह इन दोनों ऑपरेशनों में से कौन सा सही है जिसे आप पूरा करने की कोशिश कर रहे हैं। मैं प्रस्तुत करता हूं कि यदि आप अभिव्यक्ति के मूल्य का उपयोग नहीं कर रहे हैं, तो
i++इसके बजाय उपयोग करने का++iकोई कारण नहीं है, क्योंकि चर के मूल्य को कॉपी करने, चर को बढ़ाने और फिर प्रतिलिपि को फेंकने का कोई कारण नहीं है।
इसलिए, यदि परिणामी मूल्य का उपयोग नहीं किया जाता है, तो मैं उपयोग करूंगा ++i। लेकिन इसलिए नहीं कि यह अधिक कुशल है: क्योंकि यह मेरे इरादे को सही ढंग से बताता है।
i++उसी तरह मैं कोड चाहते i += nया i = i + nअर्थात रूप में, लक्ष्य क्रिया वस्तु , साथ लक्ष्य संकार्य की बाईं करने के लिए क्रिया ऑपरेटर। के मामले में i++, वहाँ कोई सही है वस्तु है, लेकिन यह नियम अब भी लागू होता है, ध्यान में रखते हुए लक्ष्य के बाईं ओर क्रिया ऑपरेटर।
एक बेहतर उत्तर यह है कि ++iकभी-कभी तेज होगा लेकिन कभी धीमा नहीं होगा।
सभी को लगता है कि iयह एक नियमित रूप से निर्मित प्रकार है int। इस मामले में कोई औसत दर्जे का अंतर नहीं होगा।
हालांकि यदि iजटिल प्रकार है तो आप एक औसत दर्जे का अंतर पा सकते हैं। इसके लिए i++आपको वेतन वृद्धि से पहले अपनी कक्षा की एक प्रति बनानी होगी। एक कॉपी में शामिल होने के आधार पर यह वास्तव में धीमा हो सकता है क्योंकि ++itआप अंतिम मूल्य वापस कर सकते हैं।
Foo Foo::operator++()
{
Foo oldFoo = *this; // copy existing value - could be slow
// yadda yadda, do increment
return oldFoo;
}एक और अंतर यह है कि ++iआपके पास मूल्य के बजाय एक संदर्भ वापस करने का विकल्प होता है। फिर, इस बात पर निर्भर करता है कि आपकी वस्तु की प्रतिलिपि बनाने में क्या शामिल है यह धीमा हो सकता है।
एक वास्तविक दुनिया का उदाहरण जहां यह हो सकता है, पुनरावृत्तियों का उपयोग होगा। अपने एप्लिकेशन में एक इट्रेटर को कॉपी करना एक बोतल-गर्दन होने की संभावना नहीं है, लेकिन परिणाम के प्रभावित होने के ++iबजाय उपयोग करने की आदत में आना अभी भी अच्छा अभ्यास है i++।
संक्षिप्त जवाब:
गति के मामले में i++और इसके बीच कोई अंतर नहीं है ++i। एक अच्छे संकलक को दो मामलों में अलग-अलग कोड उत्पन्न नहीं करना चाहिए।
लंबा जवाब:
हर दूसरा उत्तर जो उल्लेख करने में विफल रहता है वह यह है कि ++iबनाम के बीच का अंतर i++केवल उस अभिव्यक्ति के भीतर समझ में आता है जो इसे मिली है।
के मामले में for(i=0; i<n; i++), i++अकेले अपनी अभिव्यक्ति में है: वहाँ से पहले एक अनुक्रम बिंदु है i++और इसके बाद एक है। इस प्रकार उत्पन्न एकमात्र मशीन कोड "वृद्धि iद्वारा 1" है और यह अच्छी तरह से परिभाषित है कि यह कार्यक्रम के बाकी हिस्सों के संबंध में कैसे अनुक्रमित है। तो तुम उपसर्ग के लिए इसे बदल जाएगा अगर ++, ऐसा नहीं बात थोड़ी सी में, आप अभी भी सिर्फ मशीन कोड "वृद्धि मिल जाएगा iद्वारा 1"।
बीच के अंतर ++iऔर i++केवल अभिव्यक्ति जैसे कि array[i++] = x;बनाम array[++i] = x;। कुछ तर्क दे सकते हैं और कह सकते हैं कि पोस्टफिक्स ऐसे ऑपरेशनों में धीमा होगा क्योंकि रजिस्टर जहां iरहता है उसे बाद में फिर से लोड करना पड़ता है। लेकिन फिर ध्यान दें कि कंपाइलर आपके निर्देशों को किसी भी तरह से आदेश देने के लिए स्वतंत्र है, जब तक कि यह "अमूर्त मशीन के व्यवहार को नहीं तोड़ता" जैसा कि सी मानक इसे कहते हैं।
इसलिए जब आप मान सकते हैं कि array[i++] = x;मशीन कोड में अनुवाद हो जाता है:
iरजिस्टर ए में स्टोर मूल्य ।iरजिस्टर ए // अक्षम के स्टोर मूल्य क्योंकि यहां अतिरिक्त निर्देश, हमने पहले ही एक बार ऐसा किया था।i।संकलक अधिक कुशलता से कोड का उत्पादन कर सकता है, जैसे:
iरजिस्टर ए में स्टोर मूल्य ।i।सिर्फ इसलिए कि सी प्रोग्रामर के रूप में आपको यह सोचने के लिए प्रशिक्षित किया जाता है कि पोस्टफ़िक्स ++अंत में होता है, मशीन कोड को उस तरह से आदेश नहीं देना पड़ता है।
इसलिए ++C. में उपसर्ग और उपसर्ग के बीच कोई अंतर नहीं है। अब आपको C प्रोग्रामर के रूप में क्या होना चाहिए, क्या ऐसे लोग हैं, जो असंगत रूप से कुछ मामलों में उपसर्ग का उपयोग करते हैं और अन्य मामलों में उपसर्ग करते हैं, बिना किसी तर्क के। इससे पता चलता है कि वे अनिश्चित हैं कि C कैसे काम करता है या उन्हें भाषा का गलत ज्ञान है। यह हमेशा एक बुरा संकेत है, यह बदले में सुझाव देता है कि वे अंधविश्वास या "धार्मिक हठधर्मिता" के आधार पर अपने कार्यक्रम में अन्य संदिग्ध निर्णय ले रहे हैं।
"उपसर्ग ++हमेशा तेज होता है" वास्तव में एक ऐसी झूठी हठधर्मिता है जो सी-प्रोग्रामर के बीच आम है।
स्कॉट मेयर्स से एक पत्ता लेना, अधिक प्रभावी c ++ आइटम 6: वेतन वृद्धि और क्षरण संचालन के उपसर्ग और उपसर्ग रूपों के बीच भेद ।
उपसर्ग संस्करण हमेशा वस्तुओं के संबंध में उपसर्ग पर पसंद किया जाता है, विशेष रूप से पुनरावृत्तियों के संबंध में।
इसका कारण यदि आप ऑपरेटरों के कॉल पैटर्न को देखते हैं।
// Prefix
Integer& Integer::operator++()
{
*this += 1;
return *this;
}
// Postfix
const Integer Integer::operator++(int)
{
Integer oldValue = *this;
++(*this);
return oldValue;
}इस उदाहरण को देखते हुए यह देखना आसान है कि उपसर्ग ऑपरेटर हमेशा उपसर्ग से अधिक कुशल कैसे होगा। पोस्टफिक्स के उपयोग में एक अस्थायी वस्तु की आवश्यकता के कारण।
यही कारण है कि जब आप पुनरावृत्तियों का उपयोग करके उदाहरण देखते हैं तो वे हमेशा उपसर्ग संस्करण का उपयोग करते हैं।
लेकिन जैसा कि आप int के लिए बताते हैं कि संकलक अनुकूलन के कारण प्रभावी रूप से कोई अंतर नहीं है जो हो सकता है।
यदि आप माइक्रो ऑप्टिमाइज़ेशन के बारे में चिंतित हैं तो यहां एक अतिरिक्त अवलोकन है। घटते लूप्स संभवतः 'लूप' बढ़ाने से ज्यादा कुशल हो सकते हैं (निर्देश सेट आर्किटेक्चर जैसे एआरएम पर निर्भर करते हुए), दिए गए:
for (i = 0; i < 100; i++)प्रत्येक लूप पर आपको प्रत्येक के लिए एक निर्देश होगा:
1के लिए i। iकिसी से कम है 100।iएक से कम है 100।जबकि एक घटता लूप:
for (i = 100; i != 0; i--)लूप में प्रत्येक के लिए एक निर्देश होगा:
iसीपीयू रजिस्टर स्टेटस फ्लैग सेट करना, घटाना ।Z==0) के आधार पर एक सशर्त शाखा ।बेशक यह केवल तभी काम करता है जब शून्य में कमी हो!
एआरएम सिस्टम डेवलपर की गाइड से याद किया गया।
कृपया "कौन सा तेज़ है" का प्रश्न तय नहीं करना चाहिए कि किसका उपयोग करना है। संभावना है कि आप कभी भी इतना ध्यान रखने वाले नहीं हैं, और इसके अलावा, प्रोग्रामर पढ़ने का समय मशीन के समय से कहीं अधिक महंगा है।
जो भी मानव कोड पढ़ने के लिए सबसे अधिक समझ में आता है का उपयोग करें।
सबसे पहले: C के बीच अंतर i++और ++iनापाक है।
विवरण के लिए।
++iतेज हैC ++ में, ++iअधिक कुशल iff iकिसी तरह की वस्तु है जो ओवरलोडेड वेतन वृद्धि ऑपरेटर के साथ है।
क्यों?
में ++i, ऑब्जेक्ट को पहले बढ़ाया जाता है, और बाद में किसी भी अन्य फ़ंक्शन के लिए एक कॉस्ट रेफरेंस के रूप में पारित किया जा सकता है। यह संभव नहीं है यदि अभिव्यक्ति है foo(i++)क्योंकि अब वेतन वृद्धि को पहले foo()बुलाया जाना चाहिए , लेकिन पुराने मूल्य को पारित करने की आवश्यकता है foo()। नतीजतन, संकलक को iमूल पर वेतन वृद्धि ऑपरेटर को निष्पादित करने से पहले इसकी एक प्रति बनाने के लिए मजबूर किया जाता है । अतिरिक्त कंस्ट्रक्टर / डिस्ट्रक्टर कॉल खराब हिस्सा हैं।
जैसा कि ऊपर उल्लेख किया गया है, यह मौलिक प्रकारों पर लागू नहीं होता है।
i++ हो सकता हैयदि किसी भी निर्माता / विध्वंसक को बुलाने की आवश्यकता नहीं है, जो कि सी में हमेशा होता है, ++iऔर i++समान रूप से तेज़ होना चाहिए, है ना? नहीं। वे वस्तुतः समान रूप से तेज़ हैं, लेकिन छोटे अंतर हो सकते हैं, जो अधिकांश अन्य उत्तरदाताओं को गलत तरीके से मिला।
कैसे i++तेज हो सकता है?
बिंदु डेटा निर्भरता है। यदि मान को मेमोरी से लोड करने की आवश्यकता है, तो इसके बाद के दो ऑपरेशन, इसे बढ़ाने, और इसका उपयोग करने की आवश्यकता है। के साथ ++i, मूल्य वृद्धि का उपयोग करने से पहले वेतन वृद्धि की आवश्यकता है । के साथ i++, उपयोग वेतन वृद्धि पर निर्भर नहीं करता है, और सीपीयू वेतन वृद्धि ऑपरेशन के समानांतर में उपयोग ऑपरेशन कर सकता है । अंतर अधिकांश एक सीपीयू चक्र पर है, इसलिए यह वास्तव में नीच है, लेकिन यह वहां है। और यह दूसरा रास्ता है तो कई उम्मीद करेंगे।
++iया i++का उपयोग किसी अन्य अभिव्यक्ति के भीतर किया जाता है, तो उनके बीच बदलने से अभिव्यक्ति के शब्दार्थ बदल जाते हैं, इसलिए किसी भी संभावित प्रदर्शन लाभ / हानि प्रश्न से बाहर है। यदि वे स्टैंडअलोन हैं, अर्थात, ऑपरेशन का परिणाम तुरंत उपयोग नहीं किया जाता है, तो कोई भी सभ्य संकलक इसे उसी चीज़ के लिए संकलित करेगा, उदाहरण के लिए एक INCविधानसभा निर्देश।
i++और ++iएक-एक करके पाश स्थिरांक का समायोजन करके लगभग हर संभव स्थिति में दूसरे के स्थान पर इस्तेमाल किया जा सकता है ताकि वे क्या वे प्रोग्रामर के लिए कर में पास बराबर हैं। 2) भले ही दोनों एक ही निर्देश के लिए संकलित हों, लेकिन उनका निष्पादन सीपीयू के लिए अलग है। के मामले में i++, सीपीयू समान मूल्य का उपयोग करने वाले कुछ अन्य निर्देशों के समानांतर में वेतन वृद्धि की गणना कर सकता है (सीपीयू वास्तव में ऐसा करता है!), जबकि ++iसीपीयू को वेतन वृद्धि के बाद अन्य निर्देश को शेड्यूल करना होगा ।
if(++foo == 7) bar();और if(foo++ == 6) bar();कार्यात्मक रूप से समकक्ष हैं। हालांकि, दूसरा एक चक्र तेजी से हो सकता है, क्योंकि तुलना और वेतन वृद्धि को सीपीयू द्वारा समानांतर में गणना की जा सकती है। ऐसा नहीं है कि यह एकल चक्र बहुत मायने रखता है, लेकिन अंतर वहाँ है।
<उदाहरण के लिए बनाम <=) जहां ++आमतौर पर उपयोग किया जाता है, इसलिए हालांकि बीच का रूपांतरण अक्सर आसानी से संभव है।
@Mark भले ही कंपाइलर को वैरिएबल की स्टैक आधारित (स्टैक बेस्ड) अस्थायी कॉपी करने की अनुमति है और gcc (हाल के संस्करणों में) ऐसा कर रहा है, इसका मतलब यह नहीं है कि सभी कंपाइलर हमेशा ऐसा करेंगे।
मैंने अभी इसे अपने वर्तमान प्रोजेक्ट में उपयोग किए गए कंपाइलरों के साथ परीक्षण किया और 4 में से 3 इसे ऑप्टिमाइज़ नहीं करते हैं।
कभी भी यह न समझें कि कंपाइलर सही हो जाता है, खासकर यदि संभवतः तेज, लेकिन कभी भी धीमा कोड पढ़ने में उतना आसान नहीं है।
यदि आपके पास अपने कोड में किसी एक ऑपरेटर का वास्तव में बेवकूफ कार्यान्वयन नहीं है:
Alwas पसंद करता है ++ i over i ++।
सी में, कंपाइलर आम तौर पर उन्हें एक ही होने के लिए ऑप्टिमाइज़ कर सकता है यदि परिणाम अप्रयुक्त हो।
हालाँकि, C ++ में यदि वे अन्य प्रकारों का उपयोग करते हैं जो अपने स्वयं के ++ ऑपरेटरों को प्रदान करते हैं, तो उपसर्ग संस्करण पोस्टफ़िक्स संस्करण की तुलना में तेज़ होने की संभावना है। इसलिए, यदि आपको पोस्टफ़िक्स शब्दार्थ की ज़रूरत नहीं है, तो उपसर्ग ऑपरेटर का उपयोग करना बेहतर है।
मैं ऐसी स्थिति के बारे में सोच सकता हूं जहां उपसर्ग वृद्धि की तुलना में पोस्टफिक्स धीमा है:
कल्पना करें कि रजिस्टर के साथ एक प्रोसेसर Aको संचायक के रूप में उपयोग किया जाता है और यह कई निर्देशों में उपयोग किया जाने वाला एकमात्र रजिस्टर है (कुछ छोटे माइक्रोकंट्रोलर वास्तव में इस तरह हैं)।
अब एक काल्पनिक विधानसभा में निम्नलिखित कार्यक्रम और उनके अनुवाद की कल्पना करें:
उपसर्ग वृद्धि:
a = ++b + c;
; increment b
LD A, [&b]
INC A
ST A, [&b]
; add with c
ADD A, [&c]
; store in a
ST A, [&a]उपसर्ग वृद्धि:
a = b++ + c;
; load b
LD A, [&b]
; add with c
ADD A, [&c]
; store in a
ST A, [&a]
; increment b
LD A, [&b]
INC A
ST A, [&b]ध्यान दें कि कैसे मान bको फिर से लोड करने के लिए मजबूर किया गया था। उपसर्ग वृद्धि के साथ, कंपाइलर मान को बढ़ा सकता है और इसका उपयोग करने के साथ आगे बढ़ सकता है, संभवतः इसे फिर से लोड करने से बचें क्योंकि वांछित मूल्य पहले से ही वृद्धि के बाद रजिस्टर में है। हालाँकि, पोस्टफिक्स इन्क्रीमेंट के साथ, कंपाइलर को दो मानों में से एक, एक पुराना और एक बढ़े हुए मूल्य से निपटना पड़ता है, जैसा कि मैं एक और मेमोरी एक्सेस में उपरोक्त परिणाम दिखाता हूं।
बेशक, अगर वेतन वृद्धि का उपयोग नहीं किया जाता है, जैसे कि एक एकल i++;बयान, संकलक (और करता है) केवल पोस्टफ़िक्स या उपसर्ग उपयोग की परवाह किए बिना एक वेतन वृद्धि निर्देश उत्पन्न कर सकता है।
एक साइड नोट के रूप में, मैं यह उल्लेख करना चाहता हूं कि एक अभिव्यक्ति जिसमें कोई भी अतिरिक्त प्रयास के बिना b++एक के साथ परिवर्तित नहीं किया जा सकता है ++b(उदाहरण के लिए जोड़कर - 1)। इसलिए दोनों की तुलना अगर वे किसी अभिव्यक्ति का हिस्सा हैं तो वास्तव में मान्य नहीं हैं। अक्सर, जहां आप b++एक अभिव्यक्ति के अंदर उपयोग करते हैं, जिसका आप उपयोग नहीं कर सकते हैं ++b, इसलिए भले ही ++bसंभावित रूप से अधिक कुशल हों, यह बस गलत होगा। अपवाद निश्चित रूप से है यदि अभिव्यक्ति इसके लिए भीख माँग रही है (उदाहरण के लिए a = b++ + 1;जिसे बदला जा सकता है a = ++b;)।
मैं यहाँ ज्यादातर जवाबों और टिप्पणियों के माध्यम से पढ़ता रहा हूं, और मुझे एक भी उदाहरण नहीं दिखाई दिया, जिसके बारे में मैं सोच सकता था कि यह कहां i++से अधिक कुशल है ++i(और शायद आश्चर्यजनक रूप --i से अधिक कुशल थाi-- )। यह DEC PDP-11 के लिए C कंपाइलर के लिए है!
पीडीपी -11 में एक रजिस्टर और पोस्ट-इंक्रीमेंट के पूर्व-डिक्रीमेंट के लिए विधानसभा निर्देश थे, लेकिन दूसरे तरीके से नहीं। निर्देशों ने किसी भी "सामान्य-उद्देश्य" रजिस्टर को स्टैक पॉइंटर के रूप में उपयोग करने की अनुमति दी। तो अगर आप कुछ ऐसा इस्तेमाल करते हैं, *(i++)जिसे एक ही विधानसभा निर्देश में संकलित किया जा सकता है, जबकि *(++i)नहीं।
यह स्पष्ट रूप से एक बहुत ही गूढ़ उदाहरण है, लेकिन (या मुझे कहना चाहिए यह अपवाद है, जहां के बाद वेतन वृद्धि और अधिक कुशल है प्रदान करता था , के बाद से वहाँ PDP-11 सी कोड के लिए इन दिनों ज्यादा मांग नहीं है)।
--iऔर i++।
मैं हमेशा पूर्व वेतन वृद्धि पसंद करता हूँ, लेकिन ...
मैं यह बताना चाहता था कि ऑपरेटर ++ फ़ंक्शन को कॉल करने के मामले में भी, कंपाइलर अस्थायी को ऑप्टिमाइज़ कर पाएगा यदि फ़ंक्शन इनलाइन हो जाता है। चूंकि ऑपरेटर ++ आमतौर पर छोटा होता है और अक्सर हेडर में लागू होता है, इसलिए यह इनलेट होने की संभावना है।
इसलिए, व्यावहारिक उद्देश्यों के लिए, दो रूपों के प्रदर्शन के बीच अंतर होने की संभावना नहीं है। हालांकि, मैं हमेशा प्री-इन्क्रीमेंट पसंद करता हूं क्योंकि यह सीधे तौर पर व्यक्त करने के लिए बेहतर है कि मैं यह कहने की कोशिश कर रहा हूं, बजाय यह जानने के लिए आशावादी पर भरोसा किए।
इसके अलावा, ऑप्टिमाइज़र को कम करने की संभावना से मतलब है कि कंपाइलर तेजी से चलता है।
मेरा सी थोड़ा रूखा है, इसलिए मैं पहले से माफी मांगता हूं। स्पीडवाइज, मैं परिणामों को समझ सकता हूं। लेकिन, मुझे भ्रम है कि दोनों फाइलें एक ही MD5 हैश में कैसे निकलीं। हो सकता है कि लूप के लिए एक ही रन हो, लेकिन निम्नलिखित 2 लाइनों के कोड अलग-अलग विधानसभा उत्पन्न नहीं करेंगे?
myArray[i++] = "hello";बनाम
myArray[++i] = "hello";पहले वाला एरे को मान लिखता है, फिर वेतन वृद्धि i। दूसरी वेतन वृद्धि तो मैं सरणी के लिए लिखता हूं। मैं कोई असेंबली विशेषज्ञ नहीं हूं, लेकिन मैं अभी यह नहीं देखता कि कोड के इन 2 अलग-अलग लाइनों से एक ही निष्पादन योग्य कैसे उत्पन्न होगा।
केवल मेरे दो सेंट्स।
foo[i++]के लिए foo[++i]कुछ और बदल रहा है स्पष्ट रूप से कार्यक्रम अर्थ विज्ञान बदल जाएगा बिना, लेकिन एक पाश-उत्थापन अनुकूलन तर्क के बिना एक संकलक का उपयोग करते समय कुछ प्रोसेसर पर, incrementing pऔर qएक बार और फिर एक पाश जो प्रदर्शन जैसे चल रहा है *(p++)=*(q++);तेजी से एक पाश जो प्रदर्शन का उपयोग करने से हो सकता है *(++pp)=*(++q);। कुछ प्रोसेसर पर बहुत तंग छोरों के लिए गति अंतर महत्वपूर्ण (10% से अधिक) हो सकता है, लेकिन यह संभवतः सी में एकमात्र मामला है जहां पोस्ट-इंक्रीमेंट पूर्व-वेतन वृद्धि की तुलना में तेजी से होता है।