ผมอยู่ในขั้นเริ่มต้นของการเขียนโหมด 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> ...)
ความกังวลเกี่ยวกับ:
- การจัดเก็บข้อมูลในโครงสร้างที่มีขนาดใหญ่เช่นนี้มีประสิทธิภาพในการแลกเปลี่ยนกับระบบหรือไม่? ฉันต้องการหลีกเลี่ยงการจัดเก็บข้อมูลภายนอก แต่ฉันได้ทำในสิ่งที่ทำได้และฉันไม่คิดว่าชุดข้อมูลนั้นมีขนาดใหญ่ตั้งแต่แรก (สำหรับการใช้งานปกติ) เนื่องจากเป็นเพียงข้อความที่มนุษย์อ่านได้ในสัดส่วนที่เหมาะสม (ฉันวางแผนที่จะเลือกสรรข้อมูลเก่าโดยใช้เวลาที่ส่วนหัวของรายการโดยแต่ละคนจะสืบทอดช่วงเวลาที่อัปเดตล่าสุดจากลูก ๆ ของมันและจากบนต้นไม้ลงไปเรื่อย ๆ การเลือกสรรตัวนี้จะเกิดขึ้นที่ใด แน่นอน.)
- การจัดเก็บข้อมูลเช่นนี้มีการแลกเปลี่ยนประสิทธิภาพสำหรับสิ่งที่ต้องใช้หรือไม่ นั่นคือจะตั้งค่าและเรียกใช้การดำเนินการที่ต้องทนทุกข์ทรมานจากขนาดของรายการหรือไม่
คุณมีคำแนะนำอื่น ๆ เกี่ยวกับโครงสร้างที่ดีกว่านี้ไหม
org); การแทรกใน<!-- language: blah>กรณีที่จำเป็น (ขึ้นอยู่กับโหมดที่มีการแก้ไขโค้ด) สิ่งเช่นนั้น ดู README บน GitHub สำหรับข้อมูลเพิ่มเติมและความรู้สึกส่วนใหญ่ยินดีที่จะให้คำแนะนำคุณสมบัติ ยิ่งฉันรู้เรื่องนี้มาก่อนมือมากเท่าไหร่ก็ยิ่งสามารถออกแบบได้ดีขึ้นเท่านั้น แก้ไขไม่พูดถึง emacs keybindings;)