อะไรเร็วกว่า db_query, db_select หรือ EntityFieldQuery

ดังนั้นฉันจึงพยายามที่จะหาสิ่งที่เร็วกว่า db_query, db_select หรือ EntityFieldQuery ขณะนี้ฉันกำลังใช้ EntityFieldQuery ฉันกำลังคว้ารายการโหนดประมาณ 1,600 รายการ

ฉันรู้ว่านี่สามารถเก็บภาษีได้ในระบบดังนั้นฉันแค่ต้องการคิดออกว่าเป็นตัวเลือกที่ดีที่สุดในการคว้า 1600 โหนด การโกนเป็นวินาทีหรือแม้กระทั่งมิลลิวินาทีจะมีความสำคัญมากกับแอปพลิเคชันที่ฉันกำลังสร้าง

ขอบคุณล่วงหน้าสำหรับคำตอบของคุณ

database

— Jorge Calderon
แหล่งที่มา

คุณทำโปรไฟล์หรือไม่

— mpdonadio

ไม่แน่ใจคุณหมายถึงอะไร. คุณช่วยอธิบายหน่อยได้ไหม?

— Jorge Calderon

สิ่งที่คุณควรใช้ขึ้นอยู่กับสิ่งที่คุณพยายามทำอย่างแน่นอน? หากคุณสามารถให้รายละเอียดเพิ่มเติมเราอาจช่วยเหลือคุณได้ หากคุณใช้การสืบค้นจำนวนมาก db_query () เป็นวิธีที่เร็วที่สุด อย่างไรก็ตามหากคุณกำลังโหลดเอนทิตีกับมัน (entity_load) มากกว่าที่มันอาจจะไม่สำคัญเพราะเอนทิตี้ของโหลดจะช้าเมื่อทำการโหลดเอนทิตี 1600+

— donutdan4114

มีมากไปกว่าความเร็วของรหัสแบบสอบถาม / แบบสอบถาม ตัวอย่างเช่นคุณต้องการการเข้าถึงโหนดหรือไม่

— rooby

@rooby - ใช่ฉันทำ ฉันใช้ EntityFieldQuery ต่อไป แต่สำหรับความต้องการของฉันฉันต้องเข้าถึงฟิลด์กำหนดเองสามรายการในโหนด อย่างไรก็ตามคำตอบด้านล่างยังคงเป็นคำตอบที่ดีที่สุดเนื่องจาก raf ให้คำแนะนำและตัวเลขที่ค่อนข้างดี ซึ่งเป็นสิ่งที่ฉันกำลังมองหา

— Jorge Calderon

คำตอบ:

เพื่อตอบคำถามของคุณโดยย่อ db_query นั้นเร็วที่สุด! นี่คือเหตุผลข้อเท็จจริงและตัวเลขที่รวบรวมจากคำถามที่แตกต่างกันแหล่งที่มา:

googling อย่างง่ายของคำถามนี้มากับผลลัพธ์ต่อไปนี้:

For simple queries, db_query() is 22% faster than db_select()
For simple queries, db_query() is 124% faster than EFQ
For queries with two joins, db_query() is 29% faster than db_select()

และนี่

db_query():

Total Incl. Wall Time (microsec):   796 microsecs
Total Incl. CPU (microsecs):    0 microsecs
Total Incl. MemUse (bytes): 123,352 bytes
Total Incl. PeakMemUse (bytes): 124,248 bytes
Number of Function Calls:   38

db_select()

Total Incl. Wall Time (microsec):   1,118 microsecs
Total Incl. CPU (microsecs):    0 microsecs
Total Incl. MemUse (bytes): 425,216 bytes
Total Incl. PeakMemUse (bytes): 436,392 bytes
Number of Function Calls:   88

ถ้าคุณสังเกตเห็นข้างต้น db_select ทำการเรียกใช้ฟังก์ชันมากขึ้นและใช้หน่วยความจำมากกว่า db_query

ดูที่นี่เพื่อดูเหตุผลที่จะใช้ db_select
ดูที่นี่เพื่อเหตุผลว่าทำไมถึงต้องใช้ EntityFieldQuery บน db_select
ดูที่นี่สำหรับการเปรียบเทียบประสิทธิภาพของ db_query และ db_select

ฉันเดาว่าตัวเลือกควรเป็นไปตามความต้องการของคุณ EntityFieldQuery อาจช้าลง แต่มีข้อได้เปรียบมากมายเช่นไวยากรณ์แบบง่ายที่เก็บข้อมูลฟิลด์สามารถเสียบได้ข้อต่อหลวมและอีกมากมาย

— Raf
แหล่งที่มา

นี่คือสิ่งที่ฉันกำลังมองหา ขอบคุณพวง Raf

— Jorge Calderon

เป็นความคิดที่แย่มาก ๆ สำหรับ 1600 โหนดไม่ต้องใช้ API และใช้ EntityFieldQuery คุณกำลังเพิ่มประสิทธิภาพของสิ่งที่ผิด

สวัสดี Chx คุณช่วยอธิบายได้ไหม ดังนั้นจึงจำเป็นต้องดึง 1600 โหนด ฉันใช้ EntityFieldQuery อยู่แล้วดังนั้นพยายามทำความเข้าใจว่าความคิดที่ไม่ดีจะเป็นอย่างไร สิ่งที่ฉันได้พบคือ EntityFieldQuery จำกัด ในบางพื้นที่ จนถึงตอนนี้ก็ไม่มีอะไรที่ส่งผลกระทบต่อฉัน อย่างไรก็ตามรอคอยที่จะได้ยินความคิดของคุณ

— Jorge Calderon

หากคุณต้องการข้อมูลฟิลด์จาก 1600 โหนดทั้งหมดEFQEอาจเป็นประโยชน์ หากคุณมี EFQ อยู่แล้วคุณควรจะสามารถเข้าใจว่าคุณต้องการอะไรโดยดูที่หน้าแซนด์บ็อกซ์

— mikeytown2
แหล่งที่มา