क्या यूनिक्स ग्रीप लंबे या छोटे खोज शब्दों के साथ तेजी से काम करता है?

8

क्या लंबी या छोटी खोज शब्दों के लिए देखना तेज़ है? या क्या यह गति को प्रभावित करता है? दूसरे शब्दों में, क्या आपको खोज शब्द यथासंभव सटीक बनाने चाहिए?

100 से अधिक 000 फाइलें हैं और प्रत्येक फाइल में 20 से अधिक और 5000 से अधिक डेटा की पंक्तियाँ हैं। आमतौर पर grep का उपयोग खोज शब्द के केवल एक उदाहरण को खोजने के लिए किया जाता है।

मान लें कि खोज शब्द है SEARCHTERM, और यह इस तरह से एक पंक्ति में होगा:

NAD+DP+1234567890:92++UNIQUE+NAME+SEARCHTERM++12345+FI'

क्या "SEARCH" या "SEARCHTERM" की तलाश तेज है? मान लीजिए कि इस मामले में हमें परवाह नहीं है अगर हम अन्य असंबंधित लाइनों में भी मैच पाते हैं।

यह है कि मैं वर्तमान में यह कैसे कर सकता हूं:

grep NAD+DP 123* | grep SEARCHTERM

लेकिन मुझे यह काफी धीमा लगता है, फिर भी। आमतौर पर डेटा खोजने में लगभग 3-5 मिनट लगते हैं, यहां तक कि जब मैं किसी न किसी फ़ाइलनाम को जानता हूं, जो कि सीमा को लगभग 10 000 फ़ाइलों तक सीमित करता है।

तो, क्या लंबी या छोटी खोज शब्द से मदद मिलेगी? जहाँ तक मुझे पता है, grep एक निश्चित लंबाई के शब्दों के "ब्लॉक" की तलाश करता है?

— जुहा अनतिनें
स्रोत

8

कुछ संदर्भ सामग्री:

GNU grep जाने-माने बॉयर-मूर एल्गोरिथ्म का उपयोग करता है, जो पहली बार लक्ष्य स्ट्रिंग के अंतिम अक्षर के लिए दिखता है, और यह देखने के लिए एक लुकअप तालिका का उपयोग करता है कि यह बताए कि जब भी यह गैर-मिलान वर्ण पाता है तो इनपुट में इसे कितना आगे छोड़ सकता है।

से क्यों जीएनयू ग्रेप तेज है ।

एल्गोरिथ्म स्ट्रिंग को (पैटर्न) के लिए खोजा जा रहा है, लेकिन स्ट्रिंग को (पाठ) में खोजा जा रहा है। [...] सामान्य तौर पर, पैटर्न की लंबाई बढ़ने के साथ एल्गोरिथ्म तेजी से चलता है।

से बोयर-मूर स्ट्रिंग खोज एल्गोरिथ्म ।

निष्कर्ष: लंबे तार का उपयोग करें ।

अब, मनोरंजन के लिए थोड़ा सा बेंचमार्क:

# Initialisation
cd $(mktemp -d) && dd if=/dev/urandom of=random bs=1M count=1000
# Version
grep --v` # grep (GNU grep) 2.9
# Benchmark
(for s in 'short' 'this is not so short and we could even consider this as pretty long'; do for t in {1..10}; do time grep "$s" random; done; done ) 2> result

परिणाम: 0.952s शॉर्ट स्ट्रिंग के लिए औसत है, लंबी स्ट्रिंग के लिए 0.244s औसत है।

NB : लंबाई को ध्यान में रखा जाने वाला एकमात्र मानदंड नहीं है।

— SylvainD
स्रोत

0

आप SEARCH या SEARCHTERM का उपयोग करके खुद को आज़मा सकते हैं। दो grep कमांड के क्रम को बदलने का भी प्रयास करें। वैसे भी एकमात्र उपयोगी विकल्प शायद एक खोज के लिए कई सीपीयू कोर का उपयोग करना होगा। parallelआदेश देखें ।

— Golimar
स्रोत

0

मुझे नहीं लगता कि अधिक विशिष्ट खोज शब्द निर्दिष्ट करने से यह अधिक तेज़ी से दिखाई देगा।

खोज करने के लिए बहुत सारी फ़ाइलों के साथ, आपको खोज को तेज़ करने के लिए अपने डेटा को किसी तरह अनुक्रमित करना होगा।

मैं कुछ तरीके सुझा सकता हूं:

डेटाबेस (PostgreSQL या MySQL) बनाएँ, अपने डेटा को डेटाबेस में आयात करें - एक पंक्ति में एक फ़ाइल, FTS (पूर्ण पाठ खोज) सूचकांक जोड़ें। क्वेरी डेटाबेस के लिए कुछ उपयोगिता बनाएँ।
डेटाबेस में डेटा को अधिक बारीक तरीके से आयात करें, शायद एक पंक्ति में एक पंक्ति (या शायद एक से अधिक तालिका), अनुक्रमणिका बनाएं जैसे कि सूचकांक (तों) का उपयोग करके आपका डेटा खोज योग्य हो। क्वेरी डेटाबेस के लिए कुछ उपयोगिता बनाएँ।
अपनी फ़ाइलों को gitरिपॉजिटरी में जोड़ें , इसका उपयोग करके कॉम्पैक्ट git gcकरें, git grepखोज करने के लिए उपयोग करें। मेरे अनुभव में, 10x-100x के कारक git grepसे मानक से अधिक तेज हो सकता है grep।

— एमवीपी
स्रोत

0

तार्किक रूप से, एक छोटी अवधि के लिए कम सीपीयू समय की आवश्यकता होगी, जैसा grepकि कर रहा होगा

if (filechar[i] == pattern[i]) ...

कम समय। वास्तव में, मुझे लगता है कि grepमैं / ओ-बाउंड और सीपीयू-बाउंड नहीं होगा, इसलिए यह कोई फर्क नहीं पड़ेगा।

— स्कॉट
स्रोत

1

आश्चर्यजनक रूप से पर्याप्त है, यह गलत है क्योंकि grep वास्तव में स्मार्ट एल्गोरिथ्म का उपयोग कर रहा है, कृपया मेरे उत्तर को देखें।

— सिल्वेनड

खोज स्ट्रिंग जितनी लंबी होगी, उतने अधिक वर्ण इसे बेमेल होने पर छोड़ सकते हैं, इसलिए खोज और तेज़ होगी

— phuclv