Bash script; การเพิ่มประสิทธิภาพความเร็วการประมวลผล

ฉันสงสัยว่ามีแนวทางทั่วไปในการเพิ่มประสิทธิภาพสคริปต์ Bash หรือไม่

• ตัวอย่างเช่นสะดวกในการเขียนลูปมากกว่าบรรทัดคำสั่ง แต่มันเร็วกว่าในการประมวลผลสำหรับระบบหรือไม่ ตัวอย่าง:

  for i in a b c; do echo $i; done
  
  echo a
  echo b
  echo c

• บางครั้งผู้คนนำเสนอวิธีแก้ไขปัญหาต่าง ๆ สำหรับปัญหาเดียวกัน ตัวอย่างเช่นsed, cut, awkและechoมีความสามารถทั้งหมดที่จะตัดตัวเลขจากสตริง ฉันสงสัยว่าถ้าคุณสามารถบอกได้ว่ายิ่งมีจำนวนรหัสน้อยเท่าไหร่ก็ยิ่งเร็วเท่านั้นหากคุณใช้:

  1. คำสั่งเดียวกันเช่น

     STRING=abc.def
     echo ${STRING} | sed 's/.def//g'
     echo ${STRING} | sed '$s/....$//'

  2. คำสั่งต่าง ๆ เช่น

     STRING=abc.def
     echo ${STRING} | cut -d . -f 1
     echo ${STRING} | sed 's/.def//g'

เชลล์ไม่ได้ทำการปรับโครงสร้างโค้ดที่ส่งมอบมันจะตีความเพียงหนึ่งบรรทัดหลังจากที่อื่น (ไม่มีอะไรที่สมเหตุสมผลในล่ามคำสั่ง) เวลาส่วนใหญ่ที่เชลล์ใช้ไปนั้นเป็นการวิเคราะห์คำศัพท์ / การวิเคราะห์คำ / เรียกใช้งานโปรแกรมที่เรียกว่า

สำหรับการดำเนินการอย่างง่าย ๆ (อย่างเช่นข้อความที่ลงท้ายด้วยตัวอย่างในตอนท้ายของคำถาม) ฉันจะประหลาดใจถ้าเวลาในการโหลดโปรแกรมนั้นไม่ทำให้ความแตกต่างของความเร็วต่ำลง

คุณธรรมของเรื่องราวคือถ้าคุณต้องการความเร็วมากขึ้นคุณจะดีกว่าด้วยภาษาที่รวบรวม (กึ่ง) เช่น Perl หรือ Python ซึ่งเร็วกว่าที่จะเริ่มต้นด้วยซึ่งคุณสามารถเขียนการดำเนินการต่างๆที่กล่าวถึงโดยตรง และไม่ต้องโทรออกไปยังโปรแกรมภายนอกและมีตัวเลือกในการเรียกใช้โปรแกรมภายนอกหรือโทรเข้าโมดูล C (หรืออะไรก็ตาม) ที่ได้รับการปรับปรุงเพื่อทำงานส่วนใหญ่ นั่นคือเหตุผลว่าทำไมใน Fedora "การบริหารระบบน้ำตาล" (GUI, เป็นหลัก) เขียนใน Python: สามารถเพิ่ม GUI ที่ดีโดยไม่ต้องใช้ความพยายามมากเกินไปเร็วพอสำหรับแอพพลิเคชั่นดังกล่าวสามารถเข้าถึงการโทรของระบบได้โดยตรง หากความเร็วไม่เพียงพอให้คว้า C ++ หรือ C

แต่อย่าไปที่นั่นเว้นแต่คุณสามารถพิสูจน์ได้ว่าการเพิ่มประสิทธิภาพนั้นคุ้มค่ากับการสูญเสียความยืดหยุ่นและเวลาในการพัฒนา Shell สคริปต์ไม่ได้เลวร้ายเกินไปที่จะอ่าน แต่ฉันตัวสั่นเมื่อฉันจำบางสคริปต์ที่ใช้ในการติดตั้ง Ultrix ฉันเคยพยายามถอดรหัส ฉันเลิกใช้ "การเพิ่มประสิทธิภาพสคริปต์เชลล์" มากเกินไป

กฎข้อแรกของการเพิ่มประสิทธิภาพคือไม่ได้เพิ่มประสิทธิภาพ ทดสอบก่อน หากการทดสอบแสดงว่าโปรแกรมของคุณช้าเกินไปให้มองหาการปรับให้เหมาะสมที่สุด

วิธีเดียวที่จะตรวจสอบให้แน่ใจคือการใช้มาตรฐานสำหรับกรณีการใช้งานของคุณ มีกฎทั่วไปอยู่บ้าง แต่จะใช้กับปริมาณข้อมูลทั่วไปในแอปพลิเคชันทั่วไปเท่านั้น

กฎทั่วไปบางข้อซึ่งอาจเป็นจริงหรือไม่ก็ได้ในบางกรณี:

• สำหรับการประมวลผลภายในในเชลล์ ATT ksh นั้นเร็วที่สุด หากคุณทำการปรับแต่งสตริงจำนวนมากให้ใช้ ATT ksh ขีดมาเป็นอันดับสอง bash, pdksh และ zsh จะล้าหลัง
• หากคุณจำเป็นต้องเรียกใช้เชลล์บ่อยครั้งเพื่อทำงานสั้น ๆ ในแต่ละครั้ง dash จะชนะเนื่องจากเวลาเริ่มต้นต่ำ
• การเริ่มต้นกระบวนการภายนอกต้องเสียเวลาดังนั้นจึงเร็วกว่าที่จะมีไพพ์ไลน์เดียวที่มีส่วนที่ซับซ้อนกว่าไพพ์ไลน์ในลูป
• echo $fooช้ากว่าecho "$foo"เนื่องจากไม่มีเครื่องหมายอัญประกาศคู่จึงแยก$fooเป็นคำและตีความแต่ละคำว่าเป็นรูปแบบสัญลักษณ์แทนชื่อไฟล์ ที่สำคัญกว่านั้นคือพฤติกรรมที่แยกและกลมกลืนนั้นไม่ค่อยเป็นที่ต้องการ ดังนั้นอย่าลืมคำพูดคู่ใส่เสมอ ๆ "$foo"แทนตัวแปรและแทนคำสั่ง"$(foo)",
• เครื่องมือเฉพาะมักจะชนะเหนือเครื่องมือเอนกประสงค์ ตัวอย่างเช่นเครื่องมือเช่นcutหรือheadสามารถเลียนแบบด้วยsedแต่sedจะช้าลงและawkจะช้าลง การประมวลผลสตริงของเชลล์ทำงานช้า แต่สำหรับสตริงสั้น ๆ นั้นส่วนใหญ่จะเป็นการเรียกโปรแกรมภายนอก
• ภาษาขั้นสูงอื่น ๆ เช่น Perl, Python และ Ruby มักจะให้คุณเขียนอัลกอริทึมที่เร็วกว่า แต่มีเวลาเริ่มต้นที่สูงขึ้นอย่างมากดังนั้นพวกเขาจึงคุ้มค่ากับประสิทธิภาพสำหรับข้อมูลจำนวนมากเท่านั้น
• อย่างน้อยใน Linux, ไปป์มักจะเร็วกว่าไฟล์ชั่วคราว
• การใช้เชลล์สคริปต์ส่วนใหญ่อยู่ในกระบวนการ I / O-bound ดังนั้นการใช้ CPU จึงไม่สำคัญ

หายากที่ประสิทธิภาพเป็นข้อกังวลในเชลล์สคริปต์ รายการข้างต้นเป็นตัวบ่งชี้อย่างหมดจด; เป็นเรื่องปกติที่จะใช้วิธี“ ช้า” อย่างสมบูรณ์แบบในกรณีส่วนใหญ่เนื่องจากความแตกต่างมักจะเป็นเศษส่วนของเปอร์เซ็นต์

โดยปกติจุดของเชลล์สคริปต์คือการทำให้เสร็จเร็ว คุณต้องได้รับมากจากการปรับให้เหมาะสมเพื่อปรับการใช้เวลาในการเขียนสคริปต์เพิ่ม

เราจะขยายที่นี่ในตัวอย่างแบบวงกลมของเราด้านบนเพื่อแสดงคุณสมบัติด้านประสิทธิภาพของตัวแปลสคริปต์เชลล์ การเปรียบเทียบbashและdashล่ามสำหรับตัวอย่างนี้ที่กระบวนการเกิดขึ้นสำหรับแต่ละไฟล์ 30,000 ไฟล์แสดงว่าเส้นประสามารถแยกwcกระบวนการเกือบสองเท่าเร็วbash

bash-4.2$ time dash -c 'for i in *; do wc -l "$i"; done>/dev/null'
real    0m1.238s
user    0m0.309s
sys     0m0.815s


bash-4.2$ time bash -c 'for i in *; do wc -l "$i"; done>/dev/null'
real    0m1.422s
user    0m0.349s
sys     0m0.940s

การเปรียบเทียบความเร็วในการวนรอบฐานโดยไม่เรียกใช้wcกระบวนการแสดงให้เห็นว่าการวนซ้ำของเส้นประนั้นเร็วขึ้นเกือบ 6 เท่า!

$ time bash -c 'for i in *; do echo "$i">/dev/null; done'
real    0m1.715s
user    0m1.459s
sys     0m0.252s



$ time dash -c 'for i in *; do echo "$i">/dev/null; done'
real    0m0.375s
user    0m0.169s
sys     0m0.203s

การวนซ้ำยังค่อนข้างช้าในเชลล์ทั้งสองดังที่แสดงไว้ก่อนหน้านี้ดังนั้นสำหรับความสามารถในการขยายเราควรลองและใช้เทคนิคการทำงานมากขึ้นเพื่อทำซ้ำในกระบวนการที่คอมไพล์

$ time find -type f -print0 | wc -l --files0-from=- | tail -n1
    30000 total
real    0m0.299s
user    0m0.072s
sys     0m0.221s

ข้างต้นเป็นวิธีการแก้ปัญหาที่มีประสิทธิภาพมากที่สุดและแสดงให้เห็นถึงจุดที่ควรทำอย่างน้อยที่สุดเท่าที่จะทำได้ในเชลล์สคริปต์และตั้งเป้าที่จะใช้มันเพื่อเชื่อมต่อลอจิกที่มีอยู่ในชุดยูทิลิตีมากมาย

ข้อผิดพลาดของสคริปต์ที่ถูกขโมยมาจากเชลล์ทั่วไปโดยPádraig Brady