เมื่อgrepหรือsedใช้กับตัวเลือก--extended-regexpและรูปแบบ{1,9999}เป็นส่วนหนึ่งของ regexp ที่ใช้ประสิทธิภาพของคำสั่งเหล่านี้จะต่ำ เพื่อให้ชัดเจนยิ่งขึ้นมีการทดสอบด้านล่างสองสามข้อ [1] [2]
- ผลการดำเนินงานของญาติ
grep -E,egrepและsed -Eเกือบจะเท่ากันดังนั้นเฉพาะการทดสอบที่ได้ทำกับgrep -Eที่มีให้
ทดสอบ 1
$ time grep -E '[0-9]{1,99}' < /dev/null
real 0m0.002s
ทดสอบ 2
$ time grep -E '[0-9]{1,9999}' < /dev/null
> real 0m0.494s
ทดสอบ 3
$ time grep -E '[0123456789] {1,9999}' </ dev / null
> 21m43.947s จริง
ทดสอบ 4
$ time grep -E '[0123456789]+' < /dev/null
$ time grep -E '[0123456789]*' < /dev/null
$ time grep -E '[0123456789]{1,}' < /dev/null
$ time grep -P '[0123456789]{1,9999}' < /dev/null
real 0m0.002s
อะไรคือเหตุผลของความแตกต่างที่สำคัญของประสิทธิภาพ
time grep -E '[0-9]{1,99}' </dev/null time grep -E '[0-9]{1,9999}' </dev/nullแม้ว่าจะไม่มีอินพุตคำสั่งที่สองก็ช้า (ในวันที่ 16.04) ตามที่คาดไว้การละเว้น-Eและการหลบหนี{และการ}ทำงานเหมือนเดิมและการแทนที่-Eด้วย-Pจะไม่ช้า (PCRE เป็นเครื่องมือที่แตกต่างกัน) ที่น่าสนใจที่สุดเป็นเท่าใดได้เร็ว [0-9]กว่า., และแม้กระทั่งx [0123456789]กับใด ๆ ของเหล่านั้นและ{1,9999}, grepกินเป็นจำนวนมากของ RAM; ฉันไม่กล้าปล่อยให้มันวิ่งนานกว่า ~ 10 นาที
{ }จะ' 'ยกมา ; grepเปลือกผ่านพวกเขาเปลี่ยนแปลงไป อย่างไรก็ตาม{1,9999}จะเป็นอย่างรวดเร็วและง่ายขยายตัวรั้ง 1 9999เปลือกก็จะขยายไปยัง
psและtopเพื่อตรวจสอบว่าgrepผ่านข้อโต้แย้งที่คาดไว้และไม่ได้bashใช้ RAM และ CPU จำนวนมาก ฉันคาดหวังgrepและsedทั้งสองใช้ฟังก์ชั่น POSIX regexนำมาใช้ในlibcสำหรับการจับคู่ BRE / ERE; ฉันไม่ควรพูดคุยเกี่ยวกับgrepการออกแบบโดยเฉพาะยกเว้นในกรณีที่grepนักพัฒนาเลือกที่จะใช้ไลบรารีนั้น
time grep ... < /dev/nullเพื่อไม่ให้ผู้คนสับสนกับปัญหาที่เกิดขึ้นจริงกับข้อมูลที่ส่งไปgrepและสิ่งอื่น ๆ ที่ไม่เกี่ยวข้อง
[0-9]+เช่นกัน)