โครงสร้างข้อมูลที่เหมาะสมที่สุดสำหรับ API ของเราเอง


10

ผมอยู่ในขั้นเริ่มต้นของการเขียนโหมด Emacs สำคัญสำหรับเครือข่ายการแลกเปลี่ยนชุด ; หากคุณใช้ Emacs เป็นประจำสิ่งนี้จะเป็นประโยชน์กับคุณในที่สุด

เพื่อลดจำนวนการโทรที่เกิดขึ้นกับ Stack Exchange API (ต่อยอดที่ 10,000 ต่อ IP ต่อวัน)และเพื่อเป็นพลเมืองที่รับผิดชอบโดยทั่วไปฉันต้องการแคชข้อมูลที่ฉันได้รับจากเครือข่ายและเก็บไว้ในหน่วยความจำรอ สามารถเข้าถึงได้อีกครั้ง ฉันติดอยู่กับโครงสร้างข้อมูลเพื่อเก็บข้อมูลนี้

เห็นได้ชัดว่ามันจะเป็นรายการ อย่างไรก็ตามเช่นเดียวกับโครงสร้างข้อมูลใด ๆ ตัวเลือกจะต้องถูกกำหนดโดยข้อมูลที่จัดเก็บและสิ่งที่จะเข้าถึง stack-api/cacheสิ่งที่ผมอยากจะสามารถที่จะเก็บข้อมูลทั้งหมดนี้ในสัญลักษณ์เดียวเช่น ดังนั้นโดยไม่มีความกังวลใจต่อไปstack-api/cacheนี้เป็นรายการของข้อตกลงที่ได้รับการปรับปรุงล่าสุด:

`(<csite> <csite> <csite>)

<csite>จะอยู่ที่ไหน

(1362501715 . <site>)

ณ จุดนี้ทั้งหมดที่เราได้ทำมีกำหนดที่เรียบง่ายรายชื่อสมาคม แน่นอนว่าเราจะต้องไปลึก

แต่ละ<site>รายการของพารามิเตอร์ API (เฉพาะ) ตามด้วยคำถามรายการ:

`("codereview" <cquestion> <cquestion> <cquestion>)

แต่ละข้อ<cquestion>คุณเดาเอาว่าเป็นคำถามที่มีเวลาอัปเดตล่าสุด:

`(1362501715 <question>) (1362501720 . <question>)

<question>เป็นข้อเสียของquestionโครงสร้างและรายชื่อของคำตอบ (อีกครั้ง consed กับพวกเขาเวลาการปรับปรุงที่ผ่านมา):

`(<question-structure> <canswer> <canswer> <canswer>

และ `

`(1362501715 . <answer-structure>)

โครงสร้างข้อมูลนี้น่าจะอธิบายอย่างถูกต้องที่สุดเหมือนต้นไม้ แต่ผมไม่ทราบว่ามีวิธีที่ดีกว่าที่จะทำเช่นนี้เมื่อพิจารณาภาษา Emacs เสียงกระเพื่อม (ซึ่งไม่ใช่สิ่งที่แตกต่างจากเสียงกระเพื่อมคุณรู้และความรักที่ทุกคน ) . conses ที่แน่ชัดนั้นไม่จำเป็น แต่มันช่วยให้สมองของฉันห่อหุ้มมันได้ดีขึ้น <csite>ตัวอย่างเช่นฉันค่อนข้างแน่ใจว่าจะกลายเป็น

(<epoch-time> <api-param> <cquestion> <cquestion> ...)

ความกังวลเกี่ยวกับ:

  • การจัดเก็บข้อมูลในโครงสร้างที่มีขนาดใหญ่เช่นนี้มีประสิทธิภาพในการแลกเปลี่ยนกับระบบหรือไม่? ฉันต้องการหลีกเลี่ยงการจัดเก็บข้อมูลภายนอก แต่ฉันได้ทำในสิ่งที่ทำได้และฉันไม่คิดว่าชุดข้อมูลนั้นมีขนาดใหญ่ตั้งแต่แรก (สำหรับการใช้งานปกติ) เนื่องจากเป็นเพียงข้อความที่มนุษย์อ่านได้ในสัดส่วนที่เหมาะสม (ฉันวางแผนที่จะเลือกสรรข้อมูลเก่าโดยใช้เวลาที่ส่วนหัวของรายการโดยแต่ละคนจะสืบทอดช่วงเวลาที่อัปเดตล่าสุดจากลูก ๆ ของมันและจากบนต้นไม้ลงไปเรื่อย ๆ การเลือกสรรตัวนี้จะเกิดขึ้นที่ใด แน่นอน.)
  • การจัดเก็บข้อมูลเช่นนี้มีการแลกเปลี่ยนประสิทธิภาพสำหรับสิ่งที่ต้องใช้หรือไม่ นั่นคือจะตั้งค่าและเรียกใช้การดำเนินการที่ต้องทนทุกข์ทรมานจากขนาดของรายการหรือไม่

คุณมีคำแนะนำอื่น ๆ เกี่ยวกับโครงสร้างที่ดีกว่านี้ไหม


ฉันกำลัง +1 สิ่งนี้เพราะฉันต้องการโหมดนี้จริงๆ
Daniel Gratzer

@jozefg ผมต้องการมันมากเกินไปนี้ฝึกงานได้ดูดขึ้นส่วนใหญ่ของฉัน แต่เมื่อโรงเรียนเริ่มขึ้นบางส่วนความคืบหน้ามากขึ้นควรจะทำ
Sean Allred

ฉันดีใจที่ได้ติดตั้งปลั๊กอินของเบราว์เซอร์ที่อนุญาตให้ฉันใช้ Emacs เพื่อเติมเนื้อหาในกล่องข้อความ คุณกำลังจะให้ Emacs เข้าใจมาร์กอัปของ Wiki และแสดงข้อความที่จัดรูปแบบหรือไม่?
วินไคลน์

@ kevincline ไม่ความคิดก็คือมันจะทำงานที่เป็นประโยชน์: การเก็บคำถามในพื้นที่; การแก้ไขโค้ดขั้นสูง (การออกไปที่โหมดหลักขวาคล้ายกับorg); การแทรกใน<!-- language: blah>กรณีที่จำเป็น (ขึ้นอยู่กับโหมดที่มีการแก้ไขโค้ด) สิ่งเช่นนั้น ดู README บน GitHub สำหรับข้อมูลเพิ่มเติมและความรู้สึกส่วนใหญ่ยินดีที่จะให้คำแนะนำคุณสมบัติ ยิ่งฉันรู้เรื่องนี้มาก่อนมือมากเท่าไหร่ก็ยิ่งสามารถออกแบบได้ดีขึ้นเท่านั้น แก้ไขไม่พูดถึง emacs keybindings;)
Sean Allred

คำตอบ:


1

Emacs lisp ไม่เหมาะสำหรับการประมวลผลข้อมูล คุณอาจพบว่าเป็นประโยชน์ในการใช้ Common LISP สำหรับเครื่องยนต์และ Emacs สำหรับการนำเสนอเท่านั้น

แม้ว่าคุณจะตัดสินใจใช้ Emacs Lisp ฉันขอแนะนำให้คุณใช้ข้อมูลที่มีโครงสร้าง ( eieio) แทนรายการและตารางแฮชแทน alist

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.