ฉันใช้get_theme_mod()ไประยะหนึ่งในโครงการต่าง ๆ ของฉัน ฉันตัดสินใจที่จะใช้ประโยชน์จาก Theme Customization API ใน WordPress v3.4 เมื่อมันพร้อมใช้งานเพราะฉันรู้สึกว่ามันเป็นเครื่องมือที่จำเป็นสำหรับลูกค้าของฉันที่จะใช้

หลังจากนั้นครู่หนึ่งฉันเริ่มสังเกตเห็นว่าไซต์ของฉันรู้สึกซบเซากว่าปกติเล็กน้อยและ Customizer โดยเฉพาะใช้เวลาโหลดค่อนข้างนาน ผ่านความอุดมสมบูรณ์ของการทดลองและข้อผิดพลาดในระหว่างการสอบสวนของฉันฉันตัดสินใจที่จะลองสลับออกtypeเมื่อลงทะเบียนตั้งค่าของฉัน (คือ$wp_customize->add_setting()) จากการtheme_modoption

เมื่อฉันทำสิ่งนี้และสลับการเรียกทั้งหมดของฉันget_theme_mod()ไปget_option()ฉันสังเกตเห็นความเร็วที่เพิ่มขึ้นอย่างมากโดยใช้การตั้งค่าหลังซึ่งตรงข้ามกับอดีตในส่วนหน้าและโดยเฉพาะอย่างยิ่งใน Customizer ที่ด้านหลัง ฉันได้ดูผ่านคอร์ของ WordPress ในความพยายามที่จะลองและหาคำตอบว่าทำไมถึงเป็นเช่นนี้ แต่ดูเหมือนจะไม่สามารถแยกแยะว่า hangup ใดที่อยู่ในสถานการณ์นี้

ข้อมูลเชิงลึกที่ชุมชนอาจมีเกี่ยวกับget_option()การดำเนินการอย่างมีนัยสำคัญเร็วกว่าที่get_theme_mod()จะได้รับการชื่นชมอย่างมาก

คำตอบที่ใช่ฟังก์ชั่น theme_mod จะช้าลง แต่ไม่มากนักและประโยชน์ที่ได้นั้นมีมากกว่าความแตกต่าง

Theme mods ถูกเก็บไว้เป็นตัวเลือก ดังนั้นโดยพื้นฐานแล้วฟังก์ชั่น theme_mod จะล้อมรอบฟังก์ชันตัวเลือก

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

set_theme_mod('aaa',123);
set_theme_mod('bbb',456);

จากนั้นสิ่งที่ฉันได้รับในฐานข้อมูลคือแถวตัวเลือกเดียวที่มีชื่อของ theme_mods_themename ซึ่งมีอาร์เรย์ที่ทำให้เป็นอนุกรมด้วย ('aaa' => 123, 'bbb' => 456) ในนั้น

ตอนนี้get_theme_modจะช้าลงเพราะเป็นสายจริงสองget_optionสาย ก่อนอื่นจะได้รับชื่อของชุดรูปแบบ จากนั้นจะได้รับtheme_mods_themenameตัวเลือก นั่นก็คือการสูญเสียความเร็ว 50% ส่วนที่เหลือของงานที่ทำอยู่ส่วนใหญ่ในตัวกรองในที่มีการเรียกตัวกรองพิเศษ แต่ถ้าคุณมีบางสิ่งบางอย่างในตัวกรองที่ว่านี้จะไม่สำคัญ

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

set_theme_modจะค่อนข้างช้าเพราะมันทำให้เหมือนกันสองตัวเลือกรับสายเหล่านั้นแล้วมันทำให้อีกget_optionเรียกร้องให้ได้รับชื่อรูปแบบอีกครั้งแล้วมันจะupdate_optionมีชุดเต็มของตัวเลือกการเปลี่ยนแปลงในขณะนี้ สิ่งนี้ทำให้การอัพเดทฐานข้อมูลและความจริงที่ว่าการส่งข้อมูลมากขึ้นอาจเป็นสาเหตุของการชะลอตัวลงอย่างเห็นได้ชัด การอัปเดตสองสามไบต์เร็วกว่าการอัปเดตแถวที่ใหญ่กว่า แต่ไม่มากเท่าที่คุณสังเกตเห็นโดยปกติ ถ้าคุณไม่มีการตั้งค่าจำนวนมากทั้งหมด ...

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

ปัญหาเกี่ยวกับการใช้แถวตัวเลือกโดยตรงคือคุณกำลังใช้งานโดยตรงและใช้ชื่อคีย์เฉพาะสำหรับการตั้งค่า

หากฉันมีชุดรูปแบบที่เรียกว่า "AAA" และฉันสร้างชุดรูปแบบย่อยของชุดรูปแบบที่เรียกว่า "BBB" สำหรับใช้ในไซต์อื่นชุดรูปแบบ "AAA" ของฉันอาจใช้ตัวเลือกชื่อ "ตัวอย่าง" เมื่อฉันอัปเดตหนึ่งไซต์และอัปเดตตัวเลือกของฉันตอนนี้ตัวเลือกเดียวกันจะใช้กับธีมลูกของฉัน ถ้าฉันไม่ต้องการให้ทำล่ะ ถ้าฉันต้องการให้ธีมลูกใช้ชุดการตั้งค่าตัวเลือกอื่น

Theme mods โดยการรวมชื่อธีมจริง (และไม่ใช่ค่าฮาร์ดโค้ด) เป็นส่วนหนึ่งของคีย์ทำให้แน่ใจว่า "ธีม" แต่ละรายการในไซต์ใช้ชุดการตั้งค่าของตัวเอง ฉันสามารถสลับไปมาและการตั้งค่าไม่ได้ถ่ายโอนระหว่างพวกเขาพวกเขายังคงเป็นวิธีที่ฉันตั้งไว้ ง่ายขึ้นชัดเจนขึ้นและใช้งานง่ายขึ้น

และหากมีการเปลี่ยนแปลงคอร์หรือปลั๊กอินหลักในอนาคตจะปรับเปลี่ยนการทำงานของ theme_mods คุณจะได้รับประโยชน์โดยอัตโนมัติโดยไม่มีการเปลี่ยนแปลงใด ๆ Wrappers มักจะช้ากว่าซึ่งหลีกเลี่ยงไม่ได้มันเป็นลักษณะของการห่อหุ้ม อย่างไรก็ตามคุณยังคงเขียนโค้ด PHP ไม่ใช่ภาษาเครื่อง เราใช้ wrappers เช่นนี้เพื่อทำให้สิ่งต่าง ๆ ง่ายขึ้นและแยกการทำงาน ชุดรูปแบบไม่ควรจำเป็นต้องรู้หรือใส่ใจว่าตัวเลือกของพวกเขาถูกเก็บไว้ในฐานข้อมูลหรือวิธีการตั้งชื่อ ฟังก์ชัน theme_mod จัดเตรียมโซลูชันที่ง่ายกว่าที่สะอาดกว่า

get_theme_mod เป็นเพียงเสื้อคลุมรอบ ๆ get_optionเป็นเพียงเสื้อคลุมรอบในทางทฤษฎีเพราะมันเป็นอีกชั้นหนึ่งของนามธรรมมันจะทำงานช้าลง แต่ในทางปฏิบัติความแตกต่างไม่ควรใหญ่พอที่จะสังเกตเห็นโดยมนุษย์

ความแตกต่างความเร็วที่แท้จริงอาจเกิดขึ้นได้หากคุณมีรหัสที่ช้าติดอยู่ในตะขอ theme_mod

จะมีบางสิ่งเกิดขึ้นใน Customizer หรือไม่ ฉันเห็นสิ่งเดียวกันกับ OP ที่นี่

ฉันสามารถยืนยันได้ว่ามีตัวเลือกประมาณ 30 ตัวเลือกเวลาโหลด Customizer ของฉันลดลงจากประมาณ 3 วินาทีเป็นประมาณ. 5 วินาทีเมื่อสลับไปget_optionมาget_theme_mod

เรียกวิธีการโดยตรงฉันเห็นความแตกต่าง 2ms

( https://gist.github.com/anonymous/d98a46d00d52d40e7dec )

อาจไม่สามารถสังเกตเห็นได้ชัดเมื่อคุณเปรียบเทียบ API โดยตรง แต่จะต้องมีบางสิ่งบางอย่างเกี่ยวกับวิธีการใช้ใน Customizer

คุณสามารถทดสอบเวลาของget_option(100 ซ้ำ) โดยใช้รหัสนี้ (ใส่ในfunctions.phpหรือบางแห่ง):

add_action('wp','My_Test');
function My_Test(){
    var_dump(microtime(true));
    for ($i=1; $i<100; $i++) { get_option('blogdescription'); }
    var_dump(microtime(true));
    for ($i=1; $i<100; $i++) { get_theme_mod('blogdescription'); }
    var_dump(microtime(true));
    exit;
}   

ความคิดอื่น

ฉันไม่รู้ว่าถ้ามันสร้างความแตกต่าง (อาจจะเป็นนักพัฒนา Wordpress รู้ดีกว่า) แต่ฉันคิดว่าถ้าเว็บไซต์มีปริมาณการใช้งานสูงและทุกครั้งที่โหลดหน้าเว็บมันจะต้องมีตัวเลือกเป็นร้อยตัว ตัวเลือกมากมายเป็นหนึ่งget_option? แบบนี้:

update_option('my_extra_optss',  array(
      'myNAME' => 'George',
      'myAGE'  => 43 ));

จากนั้น:

$x = get_option('my_extra_optss');
$x['myNAME'];
$x['myAGE'];
................

จะทำให้บิตของไซต์เร็วขึ้นหรือไม่

TL; DR: หากคุณเป็นผู้พัฒนาธีมคุณควรใช้get_theme_mod

คำตอบแบบเต็ม:

หากคุณมีการเรียกใช้ 100 get_option จะต้องใช้ 100 แบบสอบถามไปยังฐานข้อมูลของคุณ

หากคุณมีการโทร 100 get_theme_mod จะใช้เพียง 1 แบบสอบถามไปยังฐานข้อมูลของคุณ

ทำไม? เนื่องจากตัวดัดแปลงชุดรูปแบบทั้งหมดจะถูกเก็บไว้ในแถวฐานข้อมูลเดียวและจะถูกเรียกเพียงหนึ่งเดียวในขณะที่ตัวเลือกแต่ละตัวเป็นแถวและการเรียกใช้ get_option 100 ครั้งจะส่งผลให้ 100 แบบสอบถามฐานข้อมูลและแน่นอนทำให้เว็บไซต์ของคุณช้าลง

หากธีมของคุณมีตัวเลือกมากมายให้ใช้get_theme_modจะลดจำนวนแบบสอบถามลงในฐานข้อมูล

คุณสามารถตรวจสอบประสิทธิภาพและจำนวนข้อความค้นหาได้โดยใช้Query Monitor Plugin