คำถามติดแท็ก performance

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

10
ฉันจะป้องกันไม่ให้สายยาวมาก ๆ ทำให้ Emacs ทำงานช้าได้อย่างไร
ฉันเห็นประสิทธิภาพที่หลากหลายขึ้นอยู่กับจำนวนบรรทัดใหม่ที่มีในไฟล์ที่ฉันกำลังเยี่ยมชม นี่คือตัวอย่าง ฉันมีไฟล์ JSON สองไฟล์: $ wget https://github.com/Wilfred/ReVo-utilities/blob/a4bdc40dd2656c496defc461fc19c403c8306d9f/revo-export/dictionary.json?raw=true -O one_line.json $ python -m json.tool <one_line.json >pretty_printed.json นี่เป็นไฟล์ JSON สองไฟล์ที่มีเนื้อหาเดียวกัน one_line.jsonคือ 18MiB ของ JSON โดยไม่มีการขึ้นบรรทัดใหม่ pretty_printed.jsonมีการขึ้นบรรทัดใหม่และเพิ่มช่องว่างทำให้ 41MiB อย่างไรก็ตามไฟล์ที่ใหญ่กว่าที่แบ่งออกเป็นหลายบรรทัดนั้นเร็วกว่ามากที่จะเปิดใน Emacs ทั้งในโหมด Javascript และโหมด Fundamental ทำไม Emacs ถึงมีประสิทธิภาพต่ำเช่นนี้เนื่องจากมีความยาวน้อยกว่าจริง ๆ ? มีอะไรที่ฉันสามารถทำได้เพื่อปรับปรุงประสิทธิภาพโดยไม่ต้องฟอร์แมตข้อมูลภายนอก Emacs หรือไม่?

1
ฉันจะแก้ไขปัญหา Emac ที่ช้ามากได้อย่างไร
ฉันกำลังเขียนเอกสารและฉันมีปัญหากับการทำงานของ Emacs ที่ฉันคิดว่าเพิ่งปรากฏเมื่อวานนี้ ฉันไม่ได้ทำการเปลี่ยนแปลงใด ๆ ในไฟล์ init หรือติดตั้งแพ็คเกจใหม่ใด ๆ ปัญหาคือว่าในขณะที่ฉันกำลังเขียนมีความล่าช้าที่เห็นได้ชัดมากระหว่างการกดตัวอักษรบนแป้นพิมพ์และทำให้พวกเขาปรากฏบนหน้าจอ บางครั้งฉันดูพวกเขายังพิมพ์อยู่บนหน้าจอหลังจากพิมพ์คำเสร็จ ฉันไม่ทราบว่ามีปัญหาอื่น ๆ ยกเว้นความเร็วในการพิมพ์ (ฉันเดาได้แค่ว่ามี) แต่ฉันไม่ได้สังเกตเห็น สิ่งที่สามารถทำให้เกิดปัญหานี้? มันเกิดจาก Emacs หรือเป็นเพราะประสิทธิภาพของพีซีของฉัน? โดยทั่วไปแล้วตัวแปรที่มีผลต่อประสิทธิภาพของ Emacs คืออะไร? เวอร์ชั่นของฉัน Emacs คือ GNU Emacs 24.3.1 โหมดแอคทีฟที่สำคัญคือ: น้ำยาง และโหมดที่ใช้งานเล็กน้อยคือ: สมบูรณ์อัตโนมัติ Auto-องค์ประกอบ Auto-การบีบอัด Auto-การเข้ารหัสลับ กะพริบตาเคอร์เซอร์ ชื่อไฟล์เงา font-Lock ทั่วโลกสมบูรณ์อัตโนมัติ Global-Font-Lock Global-Hl-Line สายจำนวน เมาส์ล้อ เชลล์ Dirtrack แสดง Paren Smartparens Smartparens …

3
ฉันจะทำอย่างไรเพื่อเร่งความเร็วการเริ่มต้นใช้งาน
ฉันสามารถทำสิ่งพื้นฐานบางอย่างเพื่อลดเวลาเริ่มต้นได้อย่างไร มีสิ่งใดที่ฉันควรให้ความสนใจเป็นพิเศษ หมายเหตุ: เวลาเริ่มต้นสามารถลดลงได้โดยการเริ่มต้น Emacs น้อยลง (หนึ่งครั้งต่อเซสชัน) และการเปิดไฟล์ในอินสแตนซ์ที่กำลังทำงานอยู่ คำถามนี้เกี่ยวกับการลดเวลาเริ่มต้นให้น้อยที่สุดสำหรับการเริ่มเซสชันหรือเวลาอื่น ๆ เมื่อจำเป็นต้องเริ่มต้น Emacs ดูคำถามเดียวกันที่ได้รับการตอบใน Stack Overflow พร้อมกับคำถามและคำตอบคะแนนมากกว่าบุ๊คมาร์ค "ที่ชื่นชอบ" กว่า 50 และ 30 คำตอบที่ดีที่นี่ควรเป็นมากกว่าสิ่งที่มีอยู่ใน Stack Overflow

3
ทำไม `ให้ 'เร็วขึ้นด้วยขอบเขตศัพท์?
ขณะอ่านผ่านซอร์สโค้ดของdolistมาโครฉันพบความคิดเห็นต่อไปนี้ ;; นี้ไม่ได้มีการทดสอบความน่าเชื่อถือ แต่มันก็ไม่ได้เรื่องเพราะทั้งสองความหมายเป็นที่ยอมรับสรรพสินค้าหนึ่งที่เร็วขึ้นเล็กน้อยกับการกำหนดขอบเขตแบบไดนามิกและอื่น ๆ ที่เป็นเร็วขึ้นเล็กน้อย (และมีความหมายทำความสะอาด) ที่มีการกำหนดขอบเขตของคำศัพท์ ซึ่งอ้างถึงตัวอย่างนี้ (ซึ่งฉันได้ทำให้เข้าใจง่ายขึ้น) (if lexical-binding (let ((temp list)) (while temp (let ((it (car temp))) ;; Body goes here (setq temp (cdr temp))))) (let ((temp list) it) (while temp (setq it (car temp)) ;; Body goes here (setq temp (cdr temp))))) มันทำให้ฉันประหลาดใจเมื่อเห็นletรูปแบบที่ใช้ในวง ฉันเคยคิดว่ามันช้าเมื่อเทียบกับการใช้ซ้ำ ๆsetqกับตัวแปรภายนอกเดียวกัน …

4
ฉันจะวัดประสิทธิภาพของรหัส elisp ได้อย่างไร
ฉันจะวัดประสิทธิภาพของรหัส elisp ของฉันได้อย่างไร มีเครื่องมือ / แพ็คเกจภายนอกใดบ้างที่ฉันสามารถวัดเวลาได้ นอกจากเวลาทั้งหมดแล้วฉันสามารถดูโปรไฟล์ที่แสดงเวลาที่ใช้ต่อฟังก์ชั่นได้หรือไม่ ฉันจะโปรไฟล์การใช้หน่วยความจำด้วยหรือไม่

1
อัลกอริทึมแบบไหนที่ใช้?
ฉันต้องเพิ่มจำนวนเต็มเดียวในรายการที่เรียงลำดับแล้วซึ่งจะไปในตำแหน่งที่ถูกต้อง tought แรกของฉันเป็นอะไรที่ชอบ (sort (cons newelt list) #'<) แต่ให้ที่จะถูกจัดเรียงไว้แล้วเพียงหนึ่งแทรกมีความจำเป็นจริงๆซึ่งหมายถึงวิธีการแก้ปัญหานี้อาจจะไม่เหมาะสมอย่างน่ากลัวขึ้นอยู่กับอัลกอริทึมที่ใช้โดยlistsort ดังนั้นอัลกอริทึมที่sortใช้คืออะไร ฉันจะทำสิ่งต่อไปนี้ดีขึ้นไหม (let ((tail list)) ;; The first element is never less-than (while (and tail (< newelt (cadr tail))) (setq tail (cdr tail))) (setcdr tail (cons newelt (cdr tail))) list)

2
ฉันจะปรับปรุงเวลาเริ่มต้นได้อย่างไรแม้จะมีหลายแพ็คเกจ
TL; DRฉันมีแพคเกจจำนวนมากเช่นนี้ซึ่งทำให้เจ็บเวลาเริ่มต้นของฉัน หากคุณไม่เชื่อว่าเป็นเช่นนั้นอ่านต่อ เวลาเริ่มต้น Emacs ของฉันค่อนข้างเล็ก ฉันไม่ได้ใช้use-packageฉันเพิ่งตั้ง hooks และautoloads หลาย ๆ ตัวเพื่อให้โค้ดเกือบทั้งหมดถูกเลื่อนออกไป ในความเป็นจริงสิ่งต่าง ๆ ถูกโหลดโดยปกติแล้วจะน้อยกว่าครึ่งวินาทีแม้ว่ามันจะดูเหมือนเป็นบ้าก็ตาม แต่เมื่อเวลาผ่านไปผมสังเกตเห็นว่าเวลาเริ่มต้นของฉันได้รับพิถีพิถันช้าลงอย่างลึกลับ สิ่งนี้ได้มาถึงจุดที่เวลาเริ่มต้นคือ≥ 1 วินาที ในที่สุดฉันก็มีเพียงพอและขุดลงไปในรากของปัญหา ในที่สุดฉันก็แสดงความคิดเห็น~/.emacsไฟล์ทั้งหมดของฉันและพบว่าเวลาเริ่มต้นยังคงเป็น≥ 1 วินาที อันที่จริงแล้วมันก็แค่โกนออก ~ 0.2วินาทีบางครั้งก็น้อยลง จากนั้นฉันลองemacs -qและพบว่าเวลาเริ่มต้นคือ ~ 0.1วินาที จากการตรวจสอบในส่วนของคู่มือ Elisp นี้ฉันพบว่าทำไมemacs -qลดเวลาในการเริ่มต้นให้มาก เห็นได้ชัดว่าemacs -qหยุด Emacs จากการทำสามสิ่งเมื่อเริ่มต้น: โหลดไฟล์ init ของคุณ กำลังโหลดdefault.elไฟล์ของคุณ โทร package-initialize เราได้ตัดออกไฟล์ init ของฉันแล้วเนื่องจากการแสดงความคิดเห็นทั้งหมดของฉัน~/.emacsไม่ได้ทำอะไรเลย ฉันไม่ได้ใช้default.elไฟล์เพื่อตัดออกไป ซึ่งปล่อยpackage-initializeให้เป็นผู้กระทำความผิดสำหรับการแสดงยอดฮิต เหตุใดจึงpackage-initializeต้องสละเวลาเริ่มต้นมาก …

1
มีข้อเสียในการตั้งค่า 'gc-cons-threshold` สูงมากและเก็บขยะเมื่อไม่ได้ใช้งานหรือไม่?
ฉันเพิ่มสองบรรทัดต่อไปนี้ที่ด้านบนของinit.el: (setq gc-cons-threshold (eval-when-compile (* 1024 1024 1024))) (run-with-idle-timer 2 t (lambda () (garbage-collect))) นั่นหมายความว่าแทนที่จะรวบรวมขยะทุก ๆ 800kb ของหน่วยความจำที่จัดสรร Emacs ทำเช่นนั้นเมื่อไม่ได้ใช้งานนั่นคือเมื่อการหยุดชั่วคราวไม่รบกวนฉัน (มันยังรวบรวมหลังจากจัดสรรหน่วยความจำ 1GB แล้ว แต่ฉันไม่คิดว่ามันจะเกิดขึ้น) นี่เป็นการปรับปรุงเวลาเริ่มต้นของฉันประมาณสองในสาม ในทางทฤษฎีมันควรปรับปรุงประสิทธิภาพโดยทั่วไป มีข้อเสียสำหรับวิธีนี้หรือไม่?

2
Magit ช้ามากใน Windows ฉันจะเพิ่มประสิทธิภาพได้อย่างไร
ฉันถูกบังคับให้ใช้ Windows 10 สำหรับโครงการ ใช่ฉันต้องการใช้ GNU / Linux เพื่อรักษาสติของฉันฉันพยายามที่จะถือว่า Windows เป็น bootloader สำหรับ Emacs :) น่าเสียดายที่ Magit (หนึ่งในส่วนที่ชื่นชอบของ Emacs ซึ่งประกอบขึ้นด้วยการขาดบรรทัดคำสั่งที่ดีใน Windows) ก็ช้าเหลือเกิน ฉันมี SSD, RAM 16 GB และ i7 แบบ quad-core แต่ใช้เวลาแปดวินาทีในการดำเนินการmagit-statusบนพื้นที่เก็บข้อมูลขนาดเล็ก จากนั้นเมื่อฉันต้องการที่จะทำการเปลี่ยนแปลงอีกก็จะใช้เวลาประมาณ 5 วินาทีต่อไฟล์ นี่คือสิ่งที่ฉันได้ลอง: $ git config --global core.preloadindex true $ git config --global core.fscache true $ git …

2
จะป้องกันไม่ให้ช้าลงเมื่อกระบวนการที่ด้อยกว่าสร้างเส้นยาวได้อย่างไร
ฉันใช้ Emacs กับ Geiser เพื่อแฮกรหัส Scheme ขณะที่ฉันเล่นไปรอบ ๆ ใน REPL บางครั้งฉันประเมินนิพจน์ที่ให้ผลลัพธ์จำนวนมากซึ่งมักจะอยู่ในหนึ่งบรรทัด ตัวอย่างเช่นฉันเพิ่งเล่นกับ SRFI-41 (สตรีม) และสร้างสตรีมตัวละครจากไฟล์ขนาดใหญ่ จากนั้นฉันบังคับสตรีมและ Geiser แก้ไขเนื้อหาทั้งหมดของไฟล์เป็นสตรีมอักขระลงในบัฟเฟอร์ของฉัน เกือบจะในทันที Emacs ต้องหยุดชะงักเหมือนตัวละครมากขึ้นเรื่อย ๆ ที่ต่อท้ายบรรทัดเอาท์พุทและไม่ว่าฉันจะกดค้างไว้นานเท่าไหร่C-gหรือC-c C-cไม่สามารถหยุด Emacs (หรือ Geiser) ได้ สิ่งนี้ทำให้เซสชัน Emacs ของฉันทั้งหมดเสียหายเนื่องจากตอนนี้ Emacs ไม่สนใจอินพุตของฉันอย่างสมบูรณ์โดยคิดว่าจำเป็นต้องให้ความสำคัญกับการพิมพ์สตรีมตัวละครขนาดใหญ่นี้ในบรรทัดเดียวให้เป็นบัฟเฟอร์ Geiser REPL ที่ไม่ตอบสนอง มีสิ่งที่ฉันสามารถทำได้เพื่อปกป้องเซสชั่น Emacs ของฉันจากความอยากรู้อยากเห็นของฉันทำลาย? (เพราะเหตุใด Emac จึงช้ามากเมื่อแสดงเส้นที่ยาวมากอยู่แล้ว) ฉันสามารถกำหนดขีด จำกัด ของเส้นยาวและบอก Emacs ได้ว่าไม่เป็นไรที่จะไม่พยายามแสดงเส้นที่ยาวมาก ๆ ?

2
ข้อ จำกัด ในทางปฏิบัติเกี่ยวกับขนาดไฟล์โหมดองค์กรหรือไม่
ฉันมีไฟล์โหมดองค์กรที่ทำงานประมาณ 6,000 บรรทัดพร้อมพาดหัวระดับบนสุดหนึ่งร้อยรายการ มันเริ่มต้นที่จะใช้เวลาประมาณหนึ่งนาทีในการโหลดหรือบันทึกและบางครั้งก็ส่ง emacs เข้าไปในวัชพืชและฉันต้องบังคับให้เลิกมัน คุณคิดว่านี่เป็นไฟล์ที่ใหญ่เกินกว่าจะจัดการได้จริงในโหมดองค์กรหรือไม่? คุณมีประสบการณ์กับไฟล์ที่ใหญ่กว่านี้ไหม? คุณประสบกับความล่าช้าประเภทเดียวกันหรือไม่? หรือฉันควรมองหาสาเหตุของความเชื่องช้าที่อื่นเช่นแพ็คเกจ emacs อื่น ๆ ที่ฉันติดตั้งไว้หรือไม่ บางทีฉันแค่ถาม emacs ทั่วไปมากเกินไป นี่คือ homeac emacs 24.4 บน Mac OS X Mavericks

1
การเพิ่มประสิทธิภาพการล็อคแบบอักษร
ฉันต้องการที่จะทำการจับคู่ชุดตัวอักษรของตัวล็อค ฉันมีคำจำกัดความของฟังก์ชั่นที่เริ่มต้นด้วยรายชื่อและฉันต้องการให้ชื่อเหล่านั้นถูกเน้นอยู่ภายในส่วนของฟังก์ชั่น ฉันได้สร้างฟังก์ชั่นที่ทำสิ่งนี้และลงทะเบียนเป็นฟังก์ชั่น jit-lock ด้วย jit-lock-register อย่างไรก็ตามประสิทธิภาพการทำงานค่อนข้างแย่และการเลื่อนล่าช้าในไฟล์ขนาดใหญ่ ฉันจะวัดประสิทธิภาพได้อย่างไร ถ้าฉันเพียงแค่เรียกฟังก์ชั่นของฉันในไฟล์ขนาดใหญ่ (ที่มีเวลาลอยก่อนและหลังหรือด้วย elp) ฉันได้รับประสิทธิภาพที่แตกต่างกันอย่างดุเดือดมันใช้เวลาตั้งแต่ 0.65 ถึง 12 วินาที มีวิธีแนะนำให้ใช้ประสิทธิภาพการล็อคแบบอักษรมาตรฐานหรือไม่ มีประสิทธิภาพแตกต่างกันหรือไม่ระหว่างตัวจับคู่แบบยึดที่กำหนดไว้ในแบบอักษร - ล็อค - คำหลักและเพิ่มฟังก์ชั่นผ่านทาง jit-lock-register? แก้ไข: ดูเหมือนว่าความแปรปรวนของประสิทธิภาพนั้นเกี่ยวข้องกับการรวบรวมขยะการเรียกใช้ฟังก์ชั่น jit-lock ของฉันช้าลงอย่างต่อเนื่องทุกครั้งที่เรียกใช้จนกว่าการรวบรวมขยะจะเริ่มขึ้น

1
มีห้องชุดมาตรฐานที่มีอยู่แล้วสำหรับ Emacs หรือไม่?
(คำถามนี้ไม่ได้เกี่ยวกับการเขียนโค้ดมาตรฐาน / การทำโปรไฟล์ elisp ให้ดูคำถามนี้) ชุดมาตรฐานใด ๆ มีอยู่สำหรับประสิทธิภาพของ Emacs หรือไม่ ฉันกำลังมองหาบางสิ่งบางอย่างที่เทียบเท่ากับมาตรฐานมาตรฐานทีมล่าม V8 ของหรือชุดมาตรฐานทีม pypy ของ ฉันต้องการตอบคำถามเช่น 'Emacs 24.4 เร็วกว่า 24.3 หรือไม่' มีห้องชุดมาตรฐานที่มีอยู่หรือไม่?

1
`มองย้อนกลับไป 'ประสิทธิภาพ
(looking-back … (line-beginning-position))ฉันมีโค้ดบางส่วนใช้ สตริงของเอกสารlooking-backระบุว่าดีกว่าที่จะหลีกเลี่ยงฟังก์ชั่นนี้เพราะความเชื่องช้า ฉันอยากรู้อยากเห็นว่าการเข้าใกล้จะเร็วขึ้นไหม (save-excursion (goto-char (line-beginning-position)) (looking-at regexp stuff))

1
unicode.txt slowness
ย้ายไปรอบ ๆ จุด (โดยใช้ปุ่มลูกศร) ใน XAH ของunicode.txtในfundamental-modeจะเห็นได้ชัดช้ากว่าในไฟล์ข้อความธรรมดา อักขระที่ไม่ใช่ ASCII หลายตัวเป็นปัญหาหรือไม่ มีอะไรอีกไหม เกี่ยวกับ: GNU Emacs 25.2.1 (x86_64-w64-mingw32) ของ 2017-04-24 เริ่มต้นด้วยตัวเลือก -Q
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.