การสร้างตัวแยกวิเคราะห์ JSON ประสิทธิภาพสูง

 (dave.cheney.net)
1 คะแนน โดย GN⁺ 2023-11-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทความเกี่ยวกับกระบวนการสร้างตัวแยกวิเคราะห์ JSON ประสิทธิภาพสูงด้วยภาษาโปรแกรม Go
  • โปรเจ็กต์ที่มีเป้าหมายเพื่อรองรับงานแบบสตรีมมิง เข้ากันได้กับแพ็กเกจ encoding/json และมี API แบบไม่ต้องจัดสรรหน่วยความจำหรือจัดสรรอย่างจำกัด
  • บทความอธิบายความซับซ้อนเชิงเวลาของการแยกวิเคราะห์ JSON และเน้นว่าขอบล่างของเวลาที่ใช้ประมวลผลอินพุตคือขนาดของอินพุต
  • บทความเกี่ยวกับกระบวนการทำโทเค็นไนซ์ที่แปลงสตรีมไบต์ให้เป็นสตรีมโทเค็น JSON
  • บทความอธิบายกระบวนการอ่านข้อมูลจากไฟล์ JSON และเน้นถึงความยากของการใช้ io.Reader
  • ผู้เขียนแนะนำแนวคิด byteReader ที่ทำงานคล้าย bufio.Reader แต่มี API ที่มีประสิทธิภาพมากกว่า
  • บทความเกี่ยวกับกระบวนการสแกนเพื่อระบุว่าอักขระใดเป็นโทเค็น และอักขระใดเป็นเพียงช่องว่าง
  • ผู้เขียนอธิบายวิธีปรับปรุงประสิทธิภาพของสแกนเนอร์โดยหลีกเลี่ยงการเรียกฟังก์ชันใน hot path
  • บทความเกี่ยวกับกระบวนการถอดรหัสเพื่อตรวจสอบว่าลำดับของโทเค็นถูกต้องหรือไม่
  • ผู้เขียนเสนอว่าสามารถปรับปรุงประสิทธิภาพของดีโคเดอร์ได้ด้วยการใช้ computed goto ที่เก็บเมธอดไว้โดยตรงและเรียกใช้โดยตรง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-11-06
ความเห็นจาก Hacker News
  • บทความที่ให้คำแนะนำอย่างละเอียดเกี่ยวกับการสร้าง JSON parser ประสิทธิภาพสูง
  • ผู้เขียนเสนอว่าสำหรับ JSON ไม่จำเป็นต้องทำ tokenization แบบชัดเจน และสามารถรวมการ parsing กับ tokenization เข้าด้วยกันได้
  • ผู้เขียนแนะนำให้หลีกเลี่ยงการจัดสรรหน่วยความจำบน heap ในขั้นตอน tokenization และ parsing เพื่อให้ได้ประสิทธิภาพที่ดีกว่า
  • การเลือกใช้ไลบรารี JSON อาจส่งผลต่อประสิทธิภาพอย่างมาก โดยอาจต่างกันได้ถึง 3-10 เท่า
  • บทความเสนอว่า หากคลาสที่จะ serialize หรือ deserialize เป็นที่ทราบตั้งแต่ตอน compile time แล้ว Jackson Java จะทำงานได้ดี แต่การเขียนโค้ดอย่างระมัดระวังและการทำ profiling ก็อาจช่วยเพิ่มประสิทธิภาพได้ถึง 2 เท่า
  • สำหรับสภาพแวดล้อม production ที่ต้องการประสิทธิภาพสูง ผู้เขียนแนะนำให้ดูงานของ Daniel Lemire หรือ MinIO ที่พอร์ตแนวคิดนั้นไปยัง Go
  • ผู้เขียนยังกล่าวถึงหน้า benchmark ของ JSON ใน RapidJSON ด้วย
  • มีการพูดถึงวิธีแก้ปัญหา "โรงงานขยะ" ใน tokenization ซึ่งรวมถึงการใช้ฟังก์ชันจาก byteslice ไปเป็น T แทนการใช้สตริง
  • ผู้เขียนกล่าวถึงแนวทางคล้ายกันที่ถูกใช้สร้าง tokenizer และ parser ของ GraphQL ซึ่งไม่มีการจัดสรรหน่วยความจำและทำงานได้เร็วมาก
  • ผู้เขียนพูดถึงเทคนิคที่ประหยัดพื้นที่มากกว่าซึ่งเรียกว่า computed goto
  • ผู้เขียนเสนอว่า standard library สามารถปรับปรุงได้ด้วยการออกแบบ API ที่ดีกว่า แต่ parser แบบสตรีมเต็มรูปแบบที่เติมโครงสร้างไปได้เพียงครึ่งเดียวก่อนจะพบข้อผิดพลาดนั้นไม่สมจริง
  • ผู้เขียนไม่เห็นด้วยกับแนวคิดที่ว่าการคาดหวังให้แอปพลิเคชันส่วนใหญ่มีอินพุตทั้งหมดอยู่ในหน่วยความจำนั้นเป็นเรื่องไม่สมจริง
  • บทความกล่าวขอบคุณ Phil Pearl และแนะนำให้ลองดูไลบรารี Sonic บน GitHub