ฉันค้นหาไฟล์ Emacs Lisp ทั้งหมดใน repac Emacs Git และพบว่า(goto-char (point-min))เกิดขึ้น 3621 ครั้งและ(goto-char 1)เกิดขึ้น 31 ครั้ง โดยส่วนตัวแล้วฉันเห็นจำนวนมาก(point-min)แต่ไม่มีเลย1แม้แต่ในหลาย ๆ กรณีก็มั่นใจได้ 100% ว่าพื้นที่ไม่ได้ถูก จำกัด ดังนั้นนี่คือคำถามของฉัน: (point-min)ยังคงต้องการมากกว่า1แม้แต่ในบัฟเฟอร์ที่ไม่ จำกัด ?

ฉันเดาว่า1เร็วกว่า(point-min)ไม่ว่ามันจะเป็นเรื่องเล็กน้อยเพียงใดเพราะ1เป็นค่าคงที่ในขณะที่(point-min)เรียกใช้ฟังก์ชัน นอกจาก1นี้สั้นกว่ามากคือ(point-min)1 ตัวอักษรกับ 11 ตัวอักษร

คุณจะรู้ได้อย่างไรว่าบัฟเฟอร์ไม่ได้ถูก จำกัด ?

หากคุณไม่ได้ขยายให้ถูกต้องก่อนที่คุณจะเรียกใช้ฟังก์ชั่นนี้คุณจะไม่แน่ใจ ยิ่งไปกว่านั้น "ซอฟต์แวร์ที่ยอดเยี่ยม" มักถูกนิยามว่าเป็น "การใช้งานในวิธีที่ผู้เขียนไม่เคยจินตนาการ" - ดังนั้นเราควรเตรียมพร้อมสำหรับการใช้รหัสที่ผิดปกติ

การอ่านรหัสคือ King

เมื่อคุณเขียน(goto-char 1)บุคคลที่อ่านรหัส (รวมถึงคุณในอีก 6 เดือนต่อมา) จะใช้สมองคิดอย่างมีค่า

• "เราจะรู้ได้อย่างไรว่าบัฟเฟอร์ไม่ได้ถูก จำกัด ?" และ
• "คืออักขระตัวแรก 0 หรือ 1"

โดยทั่วไปถ้าคุณไม่มี(widen)สิทธิ์มาก่อนคุณต้องมีความคิดเห็นอธิบายว่าทำไมคุณถึงมั่นใจว่าบัฟเฟอร์ไม่ได้ถูก จำกัด

ค่าใช้จ่ายเล็กน้อย

หากคุณไม่ได้ทำโปรไฟล์ของคุณและพบเป็นอย่างอื่นสมมติฐานที่ปลอดภัยคือค่าใช้จ่ายที่นี่จะไม่สำคัญ เมื่อเปรียบเทียบกับสิ่งอื่น ๆ ทั้งหมดที่ ELisp ทำ (เครือข่ายการเข้าถึงดิสก์หรือการจับคู่สตริง) (point-min)จะไม่มีค่าใช้จ่ายที่มีความหมาย (และอาจถูกกว่าดูคำตอบของ Stefan)

เพื่อเติมเต็มคำตอบของ SDS (ซึ่งผมอย่างเห็น) แม้จะมีการปรากฏตัวจะสามารถมีประสิทธิภาพมากกว่า(point-min) 1ในแง่ของความเร็วในการประมวลผลการทดสอบของฉันไม่เห็นความแตกต่างที่วัดได้ แต่ในแง่ของขนาด:

ELISP> (byte-compile '(lambda () (goto-char (point-min))))
#[nil "eb\207" [] 1]

ELISP> (byte-compile '(lambda () (goto-char 1)))
#[nil "\300b\207" [1] 1]

ELISP> 

นั่นเป็นเพราะpoint-minมีรหัสไบต์ของตัวเองและถูกเข้ารหัสและดำเนินการอย่างมีประสิทธิภาพมากเมื่อเทียบกับการเรียกใช้ฟังก์ชั่นอื่น ๆ

แน่นอนอีกเหตุผลหนึ่งที่ฉันจะใช้point-minคือฉันคิดว่าตัวเลือก1ที่ผ่านมาเป็นความผิดพลาด (บัฟเฟอร์ควรเริ่มต้นที่ 0)