Ctags: समानांतर ctags

नमस्ते,

जबकि समानांतर कार्यान्वयन में बनाया गया दिलचस्प हो सकता है, अलग-अलग निर्देशिका पर अलग-अलग ctags लॉन्च करके और फिर जेनरेट की गई फाइलों को मर्ज करके एक बड़े कोडबेस को अपडेट करना समानांतर करना संभव है (जो कि सभी फाइलों से शुरू होने वाली लाइनों को छोड़कर बस किया जा सकता है लेकिन एक और बाद में सभी फाइलों पर सॉर्ट - मर्ज का उपयोग करके)।

हालाँकि, मुझे विश्वास नहीं है कि आपको समानांतर ctags से कोई स्पीडअप मिलेगा, क्योंकि मुझे उम्मीद है कि आधुनिक मशीनें I/O बाध्य होंगी। हालांकि यह सुनिश्चित करने के लिए इसे प्रोफाइल करने की आवश्यकता होगी।

@mawww मुझे यकीन है कि https://github.com/ggreer/the_silver_searcher असहमत होगा: पलक:

एकाधिक ctags चलाना मानक emacs से समन्वय करना अत्यंत कठिन होगा https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183

@mawww मुझे यकीन है कि https://github.com/ggreer/the_silver_searcher असहमत होगा: पलक:

अच्छी बात।

एकाधिक ctags चलाना मानक emacs से समन्वय करना अत्यंत कठिन होगा https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183

एक शेल स्क्रिप्ट रैपर पहले से ही एक लंबा रास्ता तय कर सकता है, लेकिन हाँ इसे सीधे ctags में एकीकृत करना अधिक कुशल हो सकता है।

@fommil इस मामले पर उस आदमी का
और ध्यान दें कि कैसे उनके स्वयं के परीक्षणों से पता चला कि उनकी मशीनों पर बहुत सारे कार्यकर्ता धागे जल्दी से समानांतर नहीं होने से भी बदतर हो गए। यह प्यारा है, लेकिन प्रक्रिया के लिए हार्डवेयर, ओएस और डेटा पर बहुत अधिक निर्भर होने की संभावना है, इसलिए यह शायद "अच्छी तरह से, मेरे परीक्षणों में बेहतर प्रदर्शन करने के लिए एन थ्रेड्स का उपयोग करना" से अधिक समझदार होना चाहिए।

इसके अलावा, एक और कारण है कि यह मुझे इतना आकर्षित नहीं करता है कि न केवल मुझे विश्वास है कि यह हमें इतना कुछ देगा, लेकिन यह बड़ी मात्रा में त्रुटि-प्रवण कार्य होगा। वर्तमान में Ctags कोड बेस समानांतर टैग पार्सिंग थ्रेड्स का समर्थन करने के लिए बिल्कुल आकार में नहीं है। आप सभी _माइट_ अपेक्षाकृत आसानी से विभाजित करने में सक्षम हैं init/directory ट्रैवर्सल और _one सिंगल_ पार्सर थ्रेड है।
और अंत में, मुझे विश्वास है कि हमारे पास कोडबेस (और विशेष रूप से पार्सर्स में) में हर जगह प्रदर्शन करने के लिए अधिक समझदार अनुकूलन हैं।

तो निश्चित रूप से, मल्टीथ्रेडिंग शायद _can_ में _some_ लाभ हैं यदि बहुत अच्छी तरह से उपयोग किया जाता है, लेकिन यह सबसे दिलचस्प सुधार नहीं होने की संभावना है।

साथ ही, एक और कारण है कि यह मुझे इतना आकर्षित नहीं करता है कि […] वर्तमान में Ctags कोड बेस समानांतर टैग पार्सिंग थ्रेड्स का समर्थन करने के लिए बिल्कुल आकार में नहीं है। आप सभी _माइट_ अपेक्षाकृत आसानी से विभाजित करने में सक्षम हैं init/directory ट्रैवर्सल और _one सिंगल_ पार्सर थ्रेड है।

बीटीडब्लू, मेरा मतलब यह नहीं है कि कोड में इस क्षेत्र को सुधारना एक अच्छा विचार नहीं है, मुझे लगता है कि यह है (संभावित भविष्य के libctags के लिए)। मेरा मतलब सिर्फ इतना है कि यदि प्रदर्शन लक्ष्य है, तो शायद यह (वर्तमान में) प्रयास के लायक नहीं है, और इस पर ध्यान केंद्रित करने के लिए और भी महत्वपूर्ण क्षेत्र हैं।

BTW, एक प्रोफाइलर को फायर करना और एक गैज़िलियन तरीके से डेटा का एक बोझ प्रोफाइल करना शायद दिलचस्प होगा।

GNU समानांतर आपकी मदद कर सकता है।

जैसा कि पहले उल्लेख किया गया है, पठन को अनुकूलित करने से ctags में काफी तेजी आ सकती है।

यदि I/O कैश से आता है तो पार्सर्स का समानांतर निष्पादन चीजों को काफी तेज कर सकता है (और यह अक्सर ऐसा होता है जब आप किसी संपादक से निर्देशिका पर ctags चलाते हैं)।

@pragmaware IMO, एक पुस्तकालय को कांटा नहीं होना चाहिए।

यदि आप जापानी पाठ पढ़ते हैं, तो लेख देखें, https://qiita.com/dalance/items/c76141a097e25fabefe8 ।
(इस टिप्पणी को लिखने के बाद, मुझे ptags (https://github.com/dalance/ptags) के लिए git रिपॉजिटरी मिली। पेज अंग्रेजी में लिखा गया है।)

यह लेखक द्वारा विकसित ptags नामक टूल की रिपोर्ट करता है। टूल रस्ट में लिखा गया है और ctags को लपेटता है।
यह इनपुट के सेट के लिए समानांतर ctags चलाता है।
मैं इसकी आंतरिक लूट नहीं करता। हालाँकि, यह स्पष्ट रूप से कई ctags प्रक्रियाएँ चलाता है।

परिणाम काफी प्रभावशाली है। सिंगल प्रोसेसिंग से 5 गुना तेज। सीपीयू की संख्या नहीं लिखी जाती है। मेमोरी का आकार पर्याप्त हो सकता है (= 128GB)। लेखक पेज कैशे को गर्म करने के लिए उसी इनपुट सेट के लिए 10 बार ptags चलाता है।

हालांकि इन चीजों को ptags जैसे रैपर्स में किया जाना चाहिए, लेकिन इस शानदार परिणाम को नजरअंदाज करना मुश्किल है।
मैंने जल्दी हैक किया। https://github.com/masatake/ctags/tree/parallel
नया पेश किया गया विकल्प --_parallel _parallel में कई ctags प्रक्रियाओं को चलाता है।

कार्यकर्ता प्रक्रियाओं की संख्या, 8, हार्ड कोडित है। माई नोट पीसी में 8 कोर हैं।
मेमोरी 32GB है। लक्ष्य इनपुट नवीनतम लिनक्स कर्नेल स्रोत ट्री है।
मेरे .ctags काफी बालों वाली हैं।

परिणाम ज्यादातर समान है: 2 ~ 3 गुना तेज।

[yamato@master]~/var/ctags-github% cat run.sh
cat run.sh
for i in $(seq 1 5); do
    echo "#"
    echo "# TRAIL #$i"
    echo "#"
    echo "# parallel 8"
    time  ./ctags    --_parallel -R  ~/var/linux > /dev/null
    echo "# single"
    time  ./ctags -o - --sort=no -R  ~/var/linux > /dev/null
done
[yamato@master]~/var/ctags-github% bash run.sh 
bash run.sh 
#
# TRAIL #1
#
# parallel 8

real    0m29.073s
user    3m5.791s
sys 0m32.347s
# single

real    1m21.397s
user    1m14.601s
sys 0m6.521s
#
# TRAIL #2
#
# parallel 8

real    0m29.746s
user    3m4.601s
sys 0m32.175s
# single

real    1m26.660s
user    1m19.176s
sys 0m7.191s
#
# TRAIL #3
#
# parallel 8

real    0m28.290s
user    3m2.524s
sys 0m31.081s
# single

real    1m21.927s
user    1m14.775s
sys 0m6.896s
#
# TRAIL #4
#
# parallel 8

real    0m28.644s
user    3m3.839s
sys 0m31.756s
# single

real    1m13.319s
user    1m7.294s
sys 0m5.843s
#
# TRAIL #5
#
# parallel 8

real    0m29.274s
user    3m9.387s
sys 0m32.363s
# single

real    1m13.621s
user    1m7.487s
sys 0m5.941s
[yamato@master]~/var/ctags-github% 

(मैंने दोनों टैग फ़ाइल को कॉमप्रेड किया। कोई अंतर नहीं है।)

संतोषजनक से दूर, लेकिन यह शुरू करने के लिए अच्छी जगह है।

मुझे आश्चर्य है कि श्रमिकों का उत्पादन एकत्र किया जाना चाहिए या नहीं।

हाय @masatake मैं अपने सभी खुले टिकटों को बंद करने की कोशिश कर रहा हूं

मैं भविष्य में इस मद पर काम करूंगा। मैं इस मद को खुला रखना चाहूंगा क्योंकि यहां चर्चा का रिकॉर्ड मेरे लिए मूल्यवान होगा।

@masatake आप अभी भी इस टिकट को एक नए से लिंक कर सकते हैं और पूरा इतिहास बरकरार रख सकते हैं। यह वास्तव में मेरी मदद करेगा, क्योंकि मैं एक नई नौकरी के लिए अपने "मुद्दों" टैब को साफ करने की कोशिश कर रहा हूं और मैं इस टिकट की तरह अव्यवस्था नहीं चाहता।

@fommil , मैं नहीं देखता कि आप @masatake को कैसे ओवरराइड कर सकते हैं, जो यूनिवर्सल Ctags के पीछे प्रेरक शक्ति है, 2,700 कमिट बनाम आपकी कमिट काउंट शून्य के साथ। एक बार जब आप एक बग खोलते हैं (या, गिटहब भाषा में, "मुद्दा"), यह बग प्रोजेक्ट की संपत्ति बन जाती है। मेरा मानना ​​है कि आप इसे अनदेखे कर सकते हैं और इसके बारे में कोई ईमेल प्राप्त नहीं कर सकते हैं।

फिर से खोलना।

@dtikhonov @masatake कृपया इस टिकट को बंद कर दें। मेरे https://github.com/issues दृश्य में यह एकमात्र टिकट है जो मेरे काम के लिए प्रासंगिक नहीं है।

इस दृश्य से टिकट को तब तक हटाना संभव नहीं है जब तक कि टिकट बंद न हो जाए। भले ही मैं सदस्यता समाप्त कर दूं।

दरअसल, मुझे इस बात की जानकारी नहीं थी कि जब मैं टिकट बनाऊंगा तो रेपो मालिकों का यह नियंत्रण होगा, अन्यथा मैं ऐसा नहीं करता।

यदि आप इस पर काम करना चाहते हैं, तो कृपया एक नया टिकट बनाएं और इस टिकट का संदर्भ लें, सभी चर्चा संरक्षित है। या बस https://github.com/universal-ctags/ctags/issues/761#issuecomment -373720839 की सामग्री को एक नए टिकट में कॉपी पेस्ट करें।

मुझे नहीं लगता कि यह मेरे लिए पूछने के लिए बहुत कुछ है।

क्या आप सिर्फ कॉपी-पेस्ट के लिए एक अस्थायी GitHub खाता बना सकते हैं?
तो आप खुद ही कॉपी-पेस्ट कर सकते हैं।
फिर, आप खाते को हटा सकते हैं।

यकीन है, अगर इसे ठीक करने का यही एकमात्र तरीका है तो मैं ऐसा कर सकता हूं।

किया हुआ! मुझे यह टिकट बंद करने देने के लिए धन्यवाद। यह मेरे TODO कार्य को महत्वपूर्ण रूप से साफ़ करता है।