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

يمكن أن يقطع برنامج غلاف البرنامج النصي شيل شوطًا طويلاً ، ولكن نعم قد يكون من الأكثر فاعلية دمج ذلك مباشرةً في علامات الوسم.

fommil That guy حول هذه المسألة ليس واضحًا تمامًا من أين بدأ إلى أين ذهب (حسنًا ، يمكنك قراءته بين السطور ، لكن جيدًا) ، وعلى أي حال فهو ليس كثيرًا في الحقيقة. وأنا لا أقصد تجاهل أي من أعماله ، لكنني لن أثق تمامًا في نتائج شخص ما على ما يبدو قد تعلم للتو عن تعدد مؤشرات الترابط (على سبيل المثال ، بسبب مدى تدمير كائن المزامنة الذي يسيء استخدامه لأي أداء يمكن أن يقدمه MT) . لا أقول إنه ليس على حق تمامًا ، لكني سأحتاج إلى الإقناع :)
ولاحظ كيف أظهرت اختباراته أن الكثير من خيوط العمال على أجهزته سرعان ما أصبحت أسوأ من عدم وجود مواز على الإطلاق. إنه لطيف ، ولكن من المحتمل أن يعتمد بشكل كبير على الأجهزة ونظام التشغيل والبيانات المراد معالجتها ، لذلك من المحتمل أن يكون أكثر منطقية من "حسنًا ، يبدو أن استخدام خيوط N كان يؤدي بشكل أفضل في اختباراتي".

أيضًا ، هناك سبب آخر لعدم إعجابي كثيرًا هو أنني لا أعتقد أنه سيعطينا الكثير فحسب ، بل سيكون قدرًا كبيرًا من العمل المعرض للخطأ. حاليًا ، لا توجد قاعدة رموز CTags في أي شكل على الإطلاق لدعم سلاسل تحليل العلامات المتوازية. كل ما يمكنك _يمكن_ _ أن تكون قادرًا على تقسيمه بسهولة نسبيًا هو مسار init / directory و _ one single_ parser thread.
وأخيرًا ، أنا واثق من أن لدينا تحسينات أكثر منطقية للعمل في كل مكان في قاعدة الشفرة (وخاصة في المحللون).

لذا من المؤكد أن تعدد مؤشرات الترابط ربما _ يمكن أن يكون _ بعض الفوائد إذا تم استخدامه جيدًا ، ولكن من المحتمل ألا يكون التحسين الأكثر إثارة للاهتمام.

أيضًا ، هناك سبب آخر لعدم إعجابي كثيرًا بأنه [...] سيكون قدرًا كبيرًا من العمل المعرض للخطأ. حاليًا ، لا توجد قاعدة رموز CTags في أي شكل على الإطلاق لدعم سلاسل تحليل العلامات المتوازية. كل ما يمكنك _يمكن_ _ أن تكون قادرًا على تقسيمه بسهولة نسبيًا هو مسار init / directory و _ one single_ parser thread.

راجع للشغل ، لا أقصد أن تحسين هذه المنطقة في الكود ليس فكرة جيدة ، أعتقد أنها كذلك (خاصة بالنسبة للعلامات المكتوبة المستقبلية المحتملة). أعني فقط أنه إذا كان الأداء هو الهدف ، فربما لا يستحق (حاليًا) الجهد المبذول ، وهناك مجال أكثر أهمية يجب التركيز عليه.

راجع للشغل ، قد يكون إطلاق ملف تعريف وتنميط مجموعة كبيرة من البيانات بطرق جازيليون أمرًا مثيرًا للاهتمام.

موازاة جنو قد تساعدك.

كما ذكرنا سابقًا ، يمكن أن يؤدي تحسين القراءة إلى تسريع العلامات قليلاً.

يمكن أن يؤدي التنفيذ المتوازي للمحللين إلى تسريع الأمور قليلاً إذا كانت الإدخال / الإخراج تأتي من ذاكرة التخزين المؤقت (وغالبًا ما تكون هذه هي الحالة Nth التي تقوم فيها بتشغيل ctags على دليل من محرر).

pragmaware IMO ، لا ينبغي أن

إذا كنت تقرأ نصًا يابانيًا ، فراجع المقالة ، https://qiita.com/dalance/items/c76141a097e25fabefe8 .
(بعد كتابة هذا التعليق ، وجدت مستودع git لـ ptags (https://github.com/dalance/ptags). الصفحة مكتوبة باللغة الإنجليزية.)

يُبلغ عن أداة تسمى ptags قام المؤلف بتطويرها. الأداة مكتوبة في Rust و ctags.
يتم تشغيل ctags موازية لمجموعة الإدخال.
أنا لا أنهب في الداخل. ومع ذلك ، من الواضح أنه يدير عمليات ctags متعددة.

النتيجة رائعة جدا. 5 مرات أسرع من المعالجة الفردية. لم يتم كتابة عدد cpus. قد يكون حجم الذاكرة كافياً (= 128 جيجابايت). يقوم المؤلف بتشغيل 10 مرات ptags لنفس مجموعة الإدخال لجعل ذاكرة التخزين المؤقت للصفحة ساخنة.

على الرغم من أن هذه الأشياء يجب أن تتم في أغلفة مثل ptags ، إلا أنه من الصعب تجاهل هذه النتيجة الرائعة.
أنا اخترقت بسرعة. https://github.com/masatake/ctags/tree/parallel
الخيار الذي تم تقديمه حديثًا - _ المتوازي يدير عمليات متعددة لـ ctags _ Parallel.

عدد العمليات العاملة ، 8 ، مشفر بشكل ثابت. يحتوي جهاز الكمبيوتر الخاص بي على 8 نوى.
الذاكرة 32 جيجابايت. الإدخال الهدف هو أحدث شجرة مصدر لـ Linux kernel.
العلامات النقطية الخاصة بي تكفي.

والنتيجة هي نفسها في الغالب: 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 ، الذي هو القوة الدافعة وراء Universal Ctags ، مع 2700 التزام مقابل عدد الالتزامات صفر. بمجرد فتح خطأ (أو ، في لغة GitHub ، "مشكلة") ، تصبح هذه الأخطاء ملكية للمشروع. أعتقد أنه يمكنك إلغاء مشاهدته وعدم تلقي أي رسائل بريد إلكتروني حوله.

إعادة الفتح.

dtikhonovmasatake الرجاء إغلاق هذه التذكرة. إنها التذكرة الوحيدة في طريقة عرض https://github.com/issues التي لا صلة لها بعملي.

لا يمكن إزالة تذكرة من هذا العرض ما لم يتم إغلاق التذكرة. حتى لو ألغيت الاشتراك.

في الواقع ، لم أكن أدرك أن مالكي الريبو سيكون لديهم هذه السيطرة عندما أنشأت التذكرة ، وإلا لما كنت سأفعل ذلك.

إذا كنت ترغب في العمل على هذا ، يرجى إنشاء تذكرة جديدة والإشارة إلى هذه البطاقة ، يتم الاحتفاظ بكل المناقشة. أو فقط انسخ والصق محتويات https://github.com/universal-ctags/ctags/issues/761#issuecomment -373720839 في تذكرة جديدة.

لا أعتقد أن هذا كثير بالنسبة لي.

هل يمكنك إنشاء حساب GitHub مؤقت للنسخ واللصق فقط؟
لذلك يمكنك عمل نسخ ولصق بنفسك.
بعد ذلك ، يمكنك إزالة الحساب.

بالتأكيد ، إذا كانت هذه هي الطريقة الوحيدة لإصلاح ذلك ، يمكنني فعل ذلك.

فعله! شكرا للسماح لي بإغلاق هذه التذكرة. ينظف مهمة TODO الخاصة بي بشكل كبير.