वहाँ के बीच एक बड़ा प्रदर्शन अंतर है:पाइप बनाम अस्थायी फ़ाइल
मुझे यह जानकर उत्सुकता है कि विंडोज और * निक्स दोनों के लिए जवाब क्या है।
संपादित करें: मुझे पूछा जाना चाहिए: क्या बफर कैश एक अस्थायी फ़ाइल और पाइप के बीच अंतर को खत्म करता है?
एक बड़ा अंतर यह है कि पाइप के साथ, ए और बी प्रक्रियाओं को एक साथ चल रहा है, ताकि बी को उत्पादन से समाप्त होने से पहले आउटपुट पर काम करने लगे। इसके अलावा, पाइप का आकार सीमित है, इसलिए बी बी की तुलना में काफी अधिक डेटा उत्पन्न करने में सक्षम नहीं होगा; बी को पकड़ने के लिए इंतजार किया जाएगा।
यदि डेटा की मात्रा बड़ी है, तो अस्थायी फ़ाइल में लिखना डिस्क गतिविधि शामिल है, भले ही केवल फ़ाइल बनाने और फिर नष्ट करने के लिए। डेटा इन-मेमोरी बफर पूल में अच्छी तरह से रह सकता है - इसलिए वहां कोई डिस्क I/O नहीं है - यहां तक कि आश्चर्यजनक रूप से बड़ी फ़ाइलों के लिए भी। पाइप 'कभी' में लिखना डिस्क पर लिखना शामिल है।
बड़ा अंतर यह है कि पहली विधि वास्तव में ऑन-डिस्क स्टोरेज का उपयोग करती है, जबकि एक पाइप मेमोरी का उपयोग करेगी (जब तक कि आप वास्तव में पैडेंटिक न हों और स्वैप स्पेस के बारे में सोचना शुरू करें)।
प्रदर्शन-वार, स्मृति डिस्क से लगभग तेज है (लगभग हमेशा)। यह सभी ऑपरेटिंग सिस्टम के लिए आम तौर पर सच होना चाहिए।
एक temp फ़ाइल का उपयोग करते समय एकमात्र समय वास्तव में समझ में आता है कि प्रक्रिया बी को एकाधिक पास (जैसे कुछ प्रकार के वीडियो एन्कोडिंग) में डेटा की जांच करनी है। इस उपयोग के लिए, संपूर्ण डेटा स्ट्रीम को buffered करने की आवश्यकता होगी और यदि पर्याप्त डेटा हाँ था तो यह शायद इन-मेमोरी लाभ को अस्वीकार कर देगा। तो बहु-पास (तलाश-बाध्य) संचालन के लिए, एक अस्थायी फ़ाइल के साथ जाएं।
देखें, मैं सोच रहा था कि डिस्क कैश पाइप और एक अस्थायी फ़ाइल के बीच अंतर को खत्म कर देगा या नहीं। –
बड़ा मुद्दा यह है: जबकि प्रक्रिया ए * फ़ाइल * पर लिख रहा है, प्रक्रिया बी कुछ भी नहीं कर रही है (जब तक यह नहीं हो जाती)। जबकि प्रक्रिया ए * पाइप * पर लिख रहा है, प्रक्रिया बी तुरंत इसे पढ़ना शुरू कर सकती है। तो अगर ओएस ने पूरी फाइल को कैश किया हो, तब भी आपको ए को पूरा होने तक इंतजार करना पड़ेगा। और हां, फ़ाइल को "स्ट्रीम" करना संभव है (जैसे tail -f करता है) लेकिन आपको कुछ भी देखने से पहले ए को फ्लश करने की प्रतीक्षा करनी होगी। तो फिर, एक पाइप का उपयोग करें जब तक आपको तलाश करने की आवश्यकता न हो। –
@ क्रिस मुझे नहीं लगता कि प्रक्रिया बी को बिना किसी प्रक्रिया की प्रतीक्षा करनी है ए फ़ाइल में फिसल गया है। यदि प्रो बी समाप्त हो जाने से पहले प्रक्रिया बी फ़ाइल को पढ़ना शुरू कर देता है, तो कुछ भी बुरा नहीं होता है। प्रक्रिया बी का अनुरोध बफर से ही पूरा हो जाएगा। डिस्क तक बदलाव किए जाने तक इसे प्रतीक्षा करने की आवश्यकता नहीं है। या मैं यहाँ गलत हूँ? –
जब तक दीवारों से पूरी तरह से पाइप की मेरी समझ नहीं है, तो जवाब हाँ है।
एक temp फ़ाइल में लिखने में डिस्क का उपयोग, और संबंधित ओवरहेड शामिल है।
एक पाइप को लिखना, और इससे पढ़ना, स्मृति में होता है। काफी तेज।
मैंने सोचा कि एक व्यावहारिक उत्तर मदद कर सकता है। मैं उस स्क्रिप्ट को तेज़ी से अनुकूलित कर रहा हूं जिसका उपयोग मैं करता हूं जिसमें लगभग 4 कदम हैं। मैंने इसे पाइपिंग और गैर-पाइपिंग विधियों का उपयोग करने के लिए सेट किया है। यह विंडोज 7 64-बिट के तहत है।
मुझे पाइपिंग का उपयोग न करने के लिए 3% मंदी मिली। मेरे लिए यह कौन सा लायक है, क्योंकि अब मैं प्रत्येक चरण के बीच रुक सकता हूं और खिड़की के शीर्षक को अपडेट कर सकता हूं, जिसे मैं तब नहीं कर सका जब यह सब एक आदेश था।
व्यक्तिगत रूप से, मैं खिड़की के शीर्षक के लिए 3% हिट ले जाऊंगा।
जिज्ञासा के लिए, मैं एक> 20 एम फ़ाइल को grepping कर रहा हूं, फिर इसे एक विशेष पर्ल स्क्रिप्ट पर पास कर रहा हूं जो परिणामों को संशोधित करता है, फिर उन्हें SORT.EXE में निर्मित विंडो का उपयोग करके सॉर्ट कर रहा है, फिर उन्हें सिगविन के UNIQ.EXE का उपयोग करके अनइंक कर रहा है, फिर एएनएसआई-आधारित grep-result-coloring प्राप्त करने के लिए उन परिणामों को दोबारा दोहराएं। अधिकांश समय सॉर्टिंग चरण में बिताया जाता है।
आप किस विंडोज टाइटल के बारे में चर्चा कर रहे हैं? क्या आपके उत्तर में आपके द्वारा उल्लिखित प्रवाह का यह हिस्सा है? – Cristik
हां, मेरे पास कुछ स्क्रिप्ट हैं जो कुछ सेकंड लेते हैं, इसलिए वे मुझे कमांड लाइन विंडो के विंडो शीर्षक को अपडेट करने के लिए कुछ [मुझे कम करने के लिए] देते हैं और यह नहीं समझते कि यह कुछ भी नहीं कर रहा है :) – ClintL
नोट कि एक तरह का आदेश concurrency के लिए एक अवरोधक है। यह तब तक उत्पादन नहीं कर सकता जब तक कि यह अपने सभी इनपुट को पढ़ नहीं लेता है। यह देखते हुए कि आपकी टिप्पणी और सॉर्ट चरण में अधिकांश समय बिताया जाता है, यह आश्चर्य की बात नहीं है कि आपको पाइप और गैर-पाइप वाले नियंत्रण प्रवाह के बीच बहुत छोटा प्रदर्शन परिवर्तन मिला है। यदि आपकी पाइपलाइन में अवरुद्ध प्रकार नहीं है, तो आप बढ़ी हुई सहमति से समय संसाधित करने में बड़ी बचत का प्रदर्शन कर सकते हैं। –
+1 - एकमात्र चीज जिसे आप स्पष्ट रूप से उत्तर नहीं देते हैं, यह विंडोज और यूनिक्स के लिए समान है। (मुझे संदेह है कि एक अंतर होगा, लेकिन यह मूल प्रश्न में था।) – OverZealous
@OverZealous: निष्पक्ष बिंदु। मेरा जवाब विंडोज से यूनिक्स के लिए अधिक विश्वसनीय रूप से लागू होता है। विंडोज कभी-कभी यूनिक्स से थोड़ा अलग परिणाम प्राप्त करता है, लेकिन मुझे लगता है कि मेरे अंक विंडोज पर मान्य हैं। मुझे कम यकीन है कि विंडोज पाइप में कभी भी डिस्क पर लिखना शामिल नहीं है। –