गूंज और बिल्ली के निष्पादन के समय में इतना अंतर क्यों है?

Question

इस प्रश्न का उत्तर देने से मुझे एक और प्रश्न पूछना पड़ा:
मैंने सोचा कि निम्नलिखित स्क्रिप्ट एक ही काम करते हैं और दूसरा बहुत अधिक तेज़ होना चाहिए, क्योंकि पहला उपयोग catउस फ़ाइल को बार-बार खोलने की आवश्यकता है लेकिन दूसरा केवल फ़ाइल को खोलता है एक बार और फिर एक चर को प्रतिध्वनित करता है:

(सही कोड के लिए अद्यतन अनुभाग देखें।)

प्रथम:

#!/bin/sh
for j in seq 10; do
  cat input
done >> output

दूसरा:

#!/bin/sh
i=`cat input`
for j in seq 10; do
  echo $i
done >> output

जबकि इनपुट लगभग 50 मेगाबाइट है।

लेकिन जब मैंने दूसरा प्रयास किया, तो यह बहुत धीमा था, क्योंकि चर iको प्रतिध्वनित करना एक व्यापक प्रक्रिया थी। मुझे दूसरी स्क्रिप्ट के साथ कुछ समस्याएं भी मिलीं, उदाहरण के लिए आउटपुट फ़ाइल का आकार उम्मीद से कम था।

मैंने उनकी तुलना करने के लिए echoऔर catउनके पेज की जाँच की :

गूंज - पाठ की एक पंक्ति प्रदर्शित करें

बिल्ली - समवर्ती फ़ाइलें और मानक आउटपुट पर प्रिंट करें

लेकिन मुझे फर्क नहीं पड़ा।

इसलिए:

• बिल्ली इतनी तेज़ क्यों है और दूसरी स्क्रिप्ट में गूंज इतनी धीमी है?
• या चर के साथ समस्या है i? (क्योंकि इसके मैन पेज में echoकहा गया है कि यह "टेक्स्ट की एक पंक्ति" को प्रदर्शित करता है और इसलिए मुझे लगता है कि इसे केवल लघु चर के लिए अनुकूलित किया गया है, न कि बहुत लंबे वैरिएबल जैसे के लिए i। हालांकि, यह केवल एक अनुमान है।)
• और जब मैं उपयोग करता हूं तो मुझे समस्याएं क्यों हुईं echo?

---

अपडेट करें

मैं प्रयोग किया जाता है seq 10के बजाय `seq 10`गलत तरीके से। यह कोड संपादित किया गया है:

प्रथम:

#!/bin/sh
for j in `seq 10`; do
  cat input
done >> output

दूसरा:

#!/bin/sh
i=`cat input`
for j in `seq 10`; do
  echo $i
done >> output

( रूमा के लिए विशेष धन्यवाद ।)

हालाँकि, यह समस्या की बात नहीं है। भले ही लूप केवल एक बार होता है, मुझे एक ही समस्या मिलती है: की catतुलना में बहुत तेज काम करता है echo।

Comments

और किस बारे में cat $(for i in $(seq 1 10); do echo "input"; done) >> output? :)

— नेटमनक

echoतेजी से होता है। आप जो याद कर रहे हैं वह यह है कि जब आप उनका उपयोग करते हैं तो चर को उद्धृत न करके शेल को बहुत अधिक काम करते हैं।

— रोएमा

चर का उद्धरण समस्या नहीं है; समस्या चर रहा है मैं खुद को (इनपुट और आउटपुट के बीच एक मध्यवर्ती चरण के रूप में उपयोग करने यानी)।

— अलेक्जेंडर

`इको $ i` - ऐसा न करें। प्रिंटफ का उपयोग करें और तर्क को उद्धृत करें।

— PSkocik

@PSkocik मैं जो कह रहा हूं वह आप चाहते हैं printf '%s' "$i", नहीं echo $i। @cuonglm अपने उत्तर में गूंज की कुछ समस्याओं को अच्छी तरह से समझाता है। इको के साथ कुछ मामलों में भी उद्धृत करना पर्याप्त क्यों नहीं है, देखें unix.stackexchange.com/questions/65803/…

— PSkocik

Answer 1

यहाँ पर विचार करने के लिए कई चीजें हैं।

i=`cat input`

महंगा हो सकता है और गोले के बीच बहुत भिन्नताएं हैं।

यह एक सुविधा है जिसे कमांड प्रतिस्थापन कहा जाता है। यह विचार कमांड के पूरे आउटपुट को iमेमोरी में परिवर्तनशील न्यूलाइन वर्णों में माइनस करने के लिए है ।

ऐसा करने के लिए, गोले को एक उपखंड में कमांड को फोर्क करें और एक पाइप या सॉकेटपेयर के माध्यम से इसके आउटपुट को पढ़ें। आप यहाँ बहुत भिन्नता देखते हैं। यहाँ 50MiB फ़ाइल पर, मैं उदाहरण के लिए kash93 की तुलना में 6 गुना धीमा, लेकिन zsh की तुलना में थोड़ा तेज़ और दो बार तेज़ होने के रूप में देख सकता हूँ yash।

bashधीमा होने का मुख्य कारण यह है कि यह पाइप से एक बार में 128 बाइट्स (जबकि अन्य गोले 4KiB या 8KiB एक समय में पढ़ता है) से पढ़ता है और सिस्टम कॉल ओवरहेड द्वारा दंडित किया जाता है।

zshएनयूएल बाइट्स (एनयूएल बाइट्स पर अन्य गोले तोड़ने) से बचने के लिए कुछ पोस्ट-प्रोसेसिंग करने की आवश्यकता है, और yashमल्टी-बाइट वर्णों को पार्स करके और भी भारी-शुल्क प्रसंस्करण करता है।

सभी गोले को अनुगामी न्यूलाइन वर्णों को स्ट्रिप करने की आवश्यकता होती है जो वे कम या ज्यादा कुशलता से कर सकते हैं।

कुछ एनयूएल बाइट्स को दूसरों की तुलना में अधिक सुंदर तरीके से संभालना चाहते हैं और उनकी उपस्थिति की जांच कर सकते हैं।

फिर एक बार जब आपके पास स्मृति में वह बड़ा चर होता है, तो उस पर किसी भी हेरफेर में आम तौर पर अधिक मेमोरी आवंटित करना और डेटा को कॉपी करना शामिल होता है।

यहां, आप चर की सामग्री को पारित करने के लिए (पास करने का इरादा कर रहे थे) कर रहे हैं echo।

सौभाग्य से, echoआपके शेल में अंतर्निहित है, अन्यथा एर्ग सूची में बहुत लंबी त्रुटि के साथ निष्पादन विफल हो जाता । फिर भी, तर्क सूची सरणी का निर्माण संभवतः चर की सामग्री की नकल करना शामिल होगा।

आपके कमांड प्रतिस्थापन दृष्टिकोण में अन्य मुख्य समस्या यह है कि आप विभाजन + ग्लोब ऑपरेटर (चर को उद्धृत करने के लिए भूलकर) को लागू कर रहे हैं ।

उसके लिए, गोले को वर्णों की एक स्ट्रिंग के रूप में स्ट्रिंग का इलाज करने की आवश्यकता है (हालांकि कुछ गोले नहीं हैं और उस संबंध में छोटी गाड़ी हैं) तो UTF-8 स्थानों में, इसका मतलब है कि UTF-8 अनुक्रमों को पार्स करना (यदि पहले से ऐसा नहीं किया गया yashहै) , $IFSस्ट्रिंग में पात्रों के लिए देखें। यदि $IFSस्थान, टैब या न्यूलाइन (जो डिफ़ॉल्ट रूप से मामला है), एल्गोरिथ्म और भी जटिल और महंगा है। फिर, उस विभाजन से उत्पन्न शब्दों को आवंटित और कॉपी करने की आवश्यकता होती है।

ग्लोब वाला हिस्सा और भी महंगा होगा। तो उन शब्दों में से किसी ग्लोब वर्ण हो ( *, ?, [), तो खोल कुछ निर्देशिका की सामग्री पढ़ सकते हैं और कुछ महंगे पैटर्न मिलान करना होगा ( bashउदाहरण के लिए के कार्यान्वयन के लिए कुख्यात है कि कम से बहुत बुरा है)।

यदि इनपुट में कुछ ऐसा है /*/*/*/../../../*/*/*/../../../*/*/*, तो यह बहुत महंगा होगा क्योंकि इसका अर्थ है हजारों निर्देशिकाओं को सूचीबद्ध करना और यह कई सौ MiB तक विस्तारित हो सकता है।

फिर echoआम तौर पर कुछ अतिरिक्त प्रसंस्करण करेंगे। कुछ कार्यान्वयन \xतर्क में प्राप्त होने वाले अनुक्रमों का विस्तार करते हैं, जिसका अर्थ है कि सामग्री को पार्स करना और संभवतः डेटा का एक और आवंटन और प्रतिलिपि।

दूसरी ओर, ठीक है, अधिकांश शेल catमें बिल्ट-इन नहीं है, इसलिए इसका मतलब है कि एक प्रक्रिया को फोर्क करना और इसे निष्पादित करना (इसलिए कोड और लाइब्रेरी लोड करना), लेकिन पहले मंगलाचरण के बाद, वह कोड और इनपुट फ़ाइल की सामग्री स्मृति में कैश किया जाएगा। दूसरी ओर, कोई मध्यस्थ नहीं होगा। catएक समय में बड़ी मात्रा में पढ़ेगा और इसे बिना प्रसंस्करण के सीधे लिख देगा, और इसे बड़ी मात्रा में मेमोरी आवंटित करने की आवश्यकता नहीं है, बस एक बफर जो इसे पुन: उपयोग करता है।

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

यदि आप इसे catकई बार लागू करना चाहते हैं, तो कई बार लागू करने के बजाय , केवल inputकई बार पास करें cat।

yes input | head -n 100 | xargs cat

100 के बजाय 3 कमांड चलाएंगे।

चर संस्करण को अधिक विश्वसनीय बनाने के लिए, आपको उपयोग करने की आवश्यकता होगी zsh(अन्य शेल NUL बाइट्स के साथ सामना नहीं कर सकते हैं) और इसे करें:

zmodload zsh/mapfile
var=$mapfile[input]
repeat 10 print -rn -- "$var"

अगर आपको पता है कि इनपुट में NUL बाइट्स नहीं हैं, तो आप मज़बूती से इसे POSIXly कर सकते हैं (हालाँकि यह काम नहीं कर सकता जहाँ बिल्ट printfनहीं है):

i=$(cat input && echo .) || exit # add an extra .\n to avoid trimming newlines
i=${i%.} # remove that trailing dot (the \n was removed by cmdsubst)
n=10
while [ "$n" -gt 10 ]; do
  printf %s "$i"
  n=$((n - 1))
done

लेकिन यह catलूप में उपयोग करने की तुलना में कभी भी अधिक कुशल नहीं होगा (जब तक कि इनपुट बहुत छोटा न हो)।

Comments

यह उल्लेख के लायक है कि लंबे तर्क के मामले में, आप स्मृति से बाहर निकल सकते हैं । उदाहरण/bin/echo $(perl -e 'print "A"x999999')

— cuonglm

आप इस धारणा के साथ गलत हैं कि पढ़ने के आकार का एक महत्वपूर्ण प्रभाव है, इसलिए वास्तविक कारण को समझने के लिए मेरा उत्तर पढ़ें।

— विद्वान

@ सामान्य तौर पर, 128 बाइट्स के 409600 रीड्स करने में 64k के 800 रीड्स की तुलना में अधिक समय (सिस्टम टाइम) लगता है। तुलना dd bs=128 < input > /dev/nullके साथ dd bs=64 < input > /dev/null। 0.6s में से उस फ़ाइल को पढ़ने के लिए बैश करने के लिए, 0.4 readमेरे परीक्षणों में उन सिस्टम कॉल में खर्च किए जाते हैं , जबकि अन्य गोले वहां बहुत कम समय बिताते हैं।

— स्टीफन चेजलस

ठीक है, आपको वास्तविक प्रदर्शन विश्लेषण नहीं लगता है। रीड कॉल का प्रभाव (जब विभिन्न रीड साइज़ की तुलना करता है) aprox है। पूरे समय का 1% जबकि फ़ंक्शंस readwc() और trim()बर्न शेल में पूरे समय का 30% हिस्सा लगता है और यह सबसे कम संभावना है, क्योंकि इसके gprofलिए एनोटेशन के साथ कोई परिवाद नहीं है mbtowc()।

— 12

जिसका \xविस्तार किया गया है?

— मोहम्मद

Answer 2

समस्या के बारे में नहीं है catऔर echo, यह भूल गए उद्धरण चर के बारे में है $i।

बॉर्न जैसी शेल स्क्रिप्ट में (छोड़कर zsh), वैरिएबल को छोड़ना वैरिएबल glob+splitपर ऑपरेटर्स का कारण बनता है ।

$var

वास्तव में है:

glob(split($var))

तो प्रत्येक लूप पुनरावृत्ति के साथ, की पूरी सामग्री input(नई सीमाओं को छोड़कर) का विस्तार, विभाजन, ग्लोबिंग किया जाएगा। पूरी प्रक्रिया को मेमोरी आवंटित करने के लिए शेल की आवश्यकता होती है, बार-बार स्ट्रिंग को पार्स करना। यही कारण है कि आपको खराब प्रदर्शन मिला।

आप रोकने के लिए चर को उद्धृत कर सकते हैं, glob+splitलेकिन यह आपकी बहुत मदद नहीं करेगा, क्योंकि जब शेल को अभी भी बड़े स्ट्रिंग तर्क का निर्माण करने की आवश्यकता होती है और इसके लिए अपनी सामग्री को स्कैन करना echoपड़ता है ( echoबाहरी के साथ बिलिन को प्रतिस्थापित करना /bin/echoआपको तर्क सूची को बहुत लंबा या स्मृति से बाहर कर देगा। $iआकार पर निर्भर करता है )। अधिकांश echoकार्यान्वयन POSIX का अनुपालन नहीं है, \xयह प्राप्त होने वाले तर्कों में बैकलैश अनुक्रमों का विस्तार करेगा ।

इसके साथ cat, शेल को केवल प्रत्येक लूप पुनरावृत्ति को एक प्रक्रिया को स्पॉन करने की आवश्यकता होती है और catवह कॉपी i / o करेगा। सिस्टम बिल्ली की प्रक्रिया को तेज करने के लिए फ़ाइल सामग्री को भी कैश कर सकता है।

Comments

@roaima: आपने ग्लोब भाग का उल्लेख नहीं किया है, जो एक बहुत बड़ा कारण हो सकता है, कुछ ऐसा इमेजिंग करना जो /*/*/*/*../../../../*/*/*/*/../../../../फ़ाइल सामग्री में हो सकता है। बस विवरण को इंगित करना चाहते हैं ।

— congonglm

आपको धन्यवाद। यहां तक ​​कि इसके बिना, एक

— अछूता

time echo $( <xdditg106) >/dev/null real 0m0.125s user 0m0.085s sys 0m0.025s time echo "$( <xdditg106)" >/dev/null real 0m0.047s user 0m0.016s sys 0m0.022s

— netmonk

मुझे नहीं पता था कि क्यों उद्धृत करने से समस्या हल नहीं हो सकती। मुझे और विवरण चाहिए।

— मोहम्मद

@ mohammad.k: जैसा कि मैंने अपने उत्तर में लिखा है, चर चर glob+splitभाग को रोकें , और यह लूप को गति देगा। और मैंने यह भी नोट किया कि यह आपकी बहुत मदद नहीं करेगा। जब से अधिकांश शैल echoव्यवहार POSIX अनुरूप नहीं है। printf '%s' "$i"बेहतर है।

— congonglm

Answer 3

अगर तुम बुलाओ

i=`cat input`

यह आपकी शेल प्रक्रिया को 50 एमबी से 200 एमबी तक बढ़ने देता है (आंतरिक विस्तृत चरित्र कार्यान्वयन पर निर्भर करता है)। यह आपके खोल को धीमा कर सकता है लेकिन यह मुख्य समस्या नहीं है।

मुख्य समस्या यह है कि ऊपर दिए गए कमांड को पूरी फ़ाइल को शेल मेमोरी में पढ़ने की echo $iआवश्यकता है और उस फ़ाइल सामग्री पर फ़ील्ड विभाजन करने की आवश्यकता है $i। फ़ील्ड विभाजन करने के लिए, फ़ाइल के सभी पाठ को विस्तृत वर्णों में परिवर्तित करने की आवश्यकता होती है और यह वह जगह है जहाँ अधिकांश समय व्यतीत होता है।

मैंने धीमे मामले के साथ कुछ परीक्षण किए और ये परिणाम मिले:

• सबसे तेज ksh93 है
• अगला मेरा बॉर्न शेल (2x धीमा है जो ksh93 है)
• अगला बैश है (ksh93 की तुलना में 3x धीमा)
• अंतिम ksh88 है (ksh93 की तुलना में 7 गुना धीमा)

Ksh93 सबसे तेज़ है, इसका कारण यह है कि ksh93 का उपयोग mbtowc()libc से नहीं होता है , बल्कि इसका कार्यान्वयन होता है।

BTW: स्टीफन से गलती होती है कि पढ़ने के आकार पर कुछ प्रभाव पड़ता है, मैंने बोर्न शेल को 128 बाइट्स के बजाय 4096 बाइट चंक्स में पढ़ने के लिए संकलित किया और दोनों मामलों में समान प्रदर्शन प्राप्त किया।

Comments

i=`cat input`आदेश क्षेत्र बंटवारे ऐसा नहीं करता है, यह echo $iहै कि नहीं करता है। पर खर्च किया गया समय i=`cat input`नगण्य होगा echo $i, लेकिन cat inputअकेले की तुलना में नहीं , और के मामले में bash, अंतर bashछोटे हिस्से को करने के कारण सबसे अच्छा है। 128 से 4096 तक बदलने से प्रदर्शन पर कोई प्रभाव नहीं पड़ेगा echo $i, लेकिन यह वह बिंदु नहीं था जो मैं बना रहा था।

— स्टीफन चेजलस

यह भी ध्यान दें कि echo $iइनपुट की सामग्री और फाइलसिस्टम (यदि इसमें IFS या ग्लोब वर्ण हैं) के आधार पर, का प्रदर्शन काफी भिन्न होगा, यही वजह है कि मैंने अपने उत्तर में उस पर किसी भी प्रकार के गोले की तुलना नहीं की। उदाहरण के लिए, यहाँ yes | ghead -c50M, ksh93 का उत्पादन सबसे धीमा है, लेकिन yes | ghead -c50M | paste -sd: -यह सबसे तेज़ है।

— स्टीफन चेजलस

जब कुल समय के बारे में बात कर रहा था, मैं पूरे कार्यान्वयन के बारे में बात कर रहा था और हाँ, निश्चित रूप से क्षेत्र विभाजन गूंज कमांड के साथ होता है। और यह वह जगह है जहाँ पूरे समय का अधिकांश समय व्यतीत होता है।

— विद्वान

आप निश्चित रूप से सही हैं कि प्रदर्शन सामग्री $ $ i पर निर्भर करता है।

— विद्वान

Answer 4

दोनों मामलों में, लूप केवल दो बार (शब्द के seqलिए एक बार और शब्द के लिए एक बार) चलाया जाएगा 10।

Futhermore दोनों निकटवर्ती व्हाट्सएप को मर्ज करेंगे, और प्रमुख / अनुगामी व्हाट्सएप को छोड़ देंगे, ताकि आउटपुट आवश्यक रूप से इनपुट की दो प्रतियां न हों।

प्रथम

#!/bin/sh
for j in $(seq 10); do
    cat input
done >> output

दूसरा

#!/bin/sh
i="$(cat input)"
for j in $(seq 10); do
    echo "$i"
done >> output

echoधीमी गति से चलने का एक कारण यह हो सकता है कि आपके अयोग्य चर को अलग-अलग शब्दों में व्हाट्सएप पर विभाजित किया जा रहा है। 50MB के लिए जो बहुत काम आएगा। चर बोलो!

मेरा सुझाव है कि आप इन त्रुटियों को ठीक करें और फिर अपने समय का पुनर्मूल्यांकन करें।

---

मैंने इसका स्थानीय स्तर पर परीक्षण किया है। मैं के उत्पादन का उपयोग कर एक 50MB फ़ाइल बनाई tar cf - | dd bs=1M count=50। मैंने x100 के एक फैक्टर द्वारा चलाने के लिए छोरों को भी बढ़ाया ताकि टाइमिंग को एक उचित मूल्य पर बढ़ाया गया (मैंने आपके पूरे कोड में एक और लूप जोड़ा: for k in $(seq 100); do... done)। यहाँ समय हैं:

time ./1.sh

real    0m5.948s
user    0m0.012s
sys     0m0.064s

time ./2.sh

real    0m5.639s
user    0m4.060s
sys     0m0.224s

जैसा कि आप देख सकते हैं कि कोई वास्तविक अंतर नहीं है, लेकिन अगर कोई भी संस्करण echoहै जो मामूली रूप से तेज चलता है। यदि मैं उद्धरणों को हटाता हूं और आपके टूटे हुए संस्करण को 2 बार चलाता हूं, तो यह दर्शाता है कि शेल को और अधिक काम करना है जिसकी अपेक्षा की जानी चाहिए।

time ./2original.sh

real    0m12.498s
user    0m8.645s
sys     0m2.732s

Comments

दरअसल लूप दो बार नहीं बल्कि 10 बार चलता है।

— fpmurphy

आपने जैसा कहा था मैंने किया है, लेकिन समस्या हल नहीं हुई है। catसे बहुत तेज है echo। पहली स्क्रिप्ट औसतन 3 सेकंड में चलती है, लेकिन दूसरी औसत 54 सेकंड में चलती है।

— मोहम्मद

@ fpmurphy1: नहीं। मैंने अपना कोड आज़माया। लूप केवल दो बार चलता है, 10 बार नहीं।

— मोहम्मद

तीसरी बार @ mohammad.k: यदि आप अपने चर को उद्धृत करते हैं, तो समस्या दूर हो जाती है।

— रोज़ा

@roaima: कमांड क्या करता tar cf - | dd bs=1M count=50है? क्या यह अपने अंदर एक ही अक्षर के साथ एक नियमित फाइल बनाता है? यदि हां, तो मेरे मामले में इनपुट फ़ाइल पूरी तरह से सभी प्रकार के पात्रों और व्हाट्सएप के साथ अनियमित है। और फिर से, मैंने आपके उपयोग के timeरूप में उपयोग किया, और इसका परिणाम यह था कि मैंने कहा: 54 सेकंड बनाम 3 सेकंड।

— मोहम्मद

Answer 5

read की तुलना में बहुत तेज है cat

मुझे लगता है कि हर कोई इसका परीक्षण कर सकता है:

$ cd /sys/devices/system/cpu/cpu0/cpufreq
───────────────────────────────────────────────────────────────────────────────────────────
$ time for ((i=0; i<10000; i++ )); do read p < scaling_cur_freq ; done

real    0m0.232s
user    0m0.139s
sys     0m0.088s
───────────────────────────────────────────────────────────────────────────────────────────
$ time for ((i=0; i<10000; i++ )); do cat scaling_cur_freq > /dev/null ; done

real    0m9.372s
user    0m7.518s
sys     0m2.435s
───────────────────────────────────────────────────────────────────────────────────────────
$ type -a read
read is a shell builtin
───────────────────────────────────────────────────────────────────────────────────────────
$ type -a cat
cat is /bin/cat

cat9.372 सेकंड का समय लेता है। सेकंड echoलगते हैं .232।

readहै 40 गुना तेजी से ।

$pस्क्रीन पर गूँजने पर मेरा पहला परीक्षण read48 बार की तुलना में तेज़ी से हुआ cat।

Answer 6

echoस्क्रीन पर 1 लाइन डालने के लिए के लिए है। आप दूसरे उदाहरण में क्या करते हैं कि आप फ़ाइल की सामग्री को एक चर में डालते हैं और फिर आप उस चर को प्रिंट करते हैं। पहले एक में आप तुरंत स्क्रीन पर सामग्री डालते हैं।

catइस उपयोग के लिए अनुकूलित है। echoनहीं है। इसके अलावा 50Mb को एक पर्यावरण चर में रखना एक अच्छा विचार नहीं है।

Comments

जिज्ञासु। echoपाठ लिखने के लिए अनुकूलित क्यों नहीं किया जाएगा?

— रोज़ा

POSIX मानक में ऐसा कुछ भी नहीं है जो कहता है कि प्रतिध्वनि एक स्क्रीन पर एक पंक्ति डालने के लिए है।

— fpmurphy

Answer 7

यह गूंज तेज होने के बारे में नहीं है, यह इस बारे में है कि आप क्या कर रहे हैं:

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

input -> output

दूसरे मामले में आप इनपुट से चर में मेमोरी में पढ़ रहे हैं और फिर आउटपुट में चर की सामग्री लिख रहे हैं।

input -> variable
variable -> output

उत्तरार्द्ध बहुत धीमा होगा, खासकर अगर इनपुट 50 एमबी है।

Comments

मुझे लगता है कि आपको उल्लेख करना होगा कि बिल्ली को स्टड से कॉपी करने के अलावा फाइल को खोलना है और इसे स्टैडआउट में लिखना है। यह दूसरी लिपि की उत्कृष्टता है, लेकिन पहले वाले दूसरे की तुलना में बहुत बेहतर है।

— मोहम्मद

दूसरी लिपि में कोई उत्कृष्टता नहीं है; बिल्ली को दोनों मामलों में इनपुट फ़ाइल खोलने की आवश्यकता है। पहले मामले में बिल्ली का डंडा सीधे फाइल पर जाता है। दूसरे मामले में बिल्ली का ठहराव पहले एक चर पर जाता है, और फिर आप चर को आउटपुट फ़ाइल में प्रिंट करते हैं।

— अलेक्जेंडर

@ mohammad.k, दूसरी स्क्रिप्ट में सशक्त रूप से कोई "उत्कृष्टता" नहीं है।

— वाइल्डकार्ड