การประกาศอาร์เรย์หลายรายการด้วยองค์ประกอบ 64 รายการเร็วกว่าการประกาศอาร์เรย์ 65 องค์ประกอบ 1,000 เท่า

เมื่อเร็ว ๆ นี้ฉันสังเกตเห็นว่าการประกาศอาร์เรย์ที่มี 64 องค์ประกอบนั้นเร็วกว่ามาก (> 1,000 เท่า) กว่าการประกาศอาร์เรย์ประเภทเดียวกันที่มี 65 องค์ประกอบ

นี่คือรหัสที่ฉันใช้ทดสอบสิ่งนี้:

public class Tests{
    public static void main(String args[]){
        double start = System.nanoTime();
        int job = 100000000;//100 million
        for(int i = 0; i < job; i++){
            double[] test = new double[64];
        }
        double end = System.nanoTime();
        System.out.println("Total runtime = " + (end-start)/1000000 + " ms");
    }
}

สิ่งนี้จะทำงานในเวลาประมาณ 6 มิลลิวินาทีหากฉันแทนที่new double[64]ด้วยnew double[65]จะใช้เวลาประมาณ 7 วินาที ปัญหานี้จะรุนแรงขึ้นอย่างทวีคูณหากงานกระจายไปทั่วเธรดมากขึ้นเรื่อย ๆ ซึ่งเป็นที่มาของปัญหาของฉัน

ปัญหานี้ยังเกิดขึ้นกับชนิดของอาร์เรย์เช่นหรือint[65] String[65]ปัญหานี้ไม่เกิดขึ้นกับสตริงขนาดใหญ่: String test = "many characters";แต่จะเริ่มเกิดขึ้นเมื่อสิ่งนี้ถูกเปลี่ยนเป็นString test = i + "";

ฉันสงสัยว่าเหตุใดจึงเป็นเช่นนั้นและหากเป็นไปได้ที่จะหลีกเลี่ยงปัญหานี้

คุณกำลังสังเกตพฤติกรรมที่เกิดจากการเพิ่มประสิทธิภาพที่ทำโดยคอมไพเลอร์ JIT ของ Java VM ของคุณ ลักษณะการทำงานนี้สามารถทริกเกอร์ซ้ำได้โดยมีอาร์เรย์สเกลาร์มากถึง 64 องค์ประกอบและไม่ถูกทริกเกอร์ด้วยอาร์เรย์ที่มีขนาดใหญ่กว่า 64

ก่อนที่จะลงรายละเอียดเรามาดูเนื้อหาของลูปอย่างละเอียด:

double[] test = new double[64];

ร่างกายไม่มีผล(ติดตามพฤติกรรม) นั่นหมายความว่าไม่มีความแตกต่างนอกเหนือจากการทำงานของโปรแกรมไม่ว่าจะมีการใช้คำสั่งนี้หรือไม่ เช่นเดียวกับการวนซ้ำทั้งหมด ดังนั้นจึงอาจเกิดขึ้นได้ที่เครื่องมือเพิ่มประสิทธิภาพโค้ดจะแปลลูปเป็นบางสิ่ง(หรือไม่มีอะไรเลย)ด้วยพฤติกรรมการทำงานที่เหมือนกันและเวลาที่แตกต่างกัน

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

• อุ่นเครื่องคอมไพเลอร์ JIT (และเครื่องมือเพิ่มประสิทธิภาพ) โดยเรียกใช้เกณฑ์มาตรฐานหลาย ๆ ครั้ง
• ใช้ผลลัพธ์ของทุกนิพจน์และพิมพ์ที่ส่วนท้ายของเกณฑ์มาตรฐาน

ตอนนี้เรามาดูรายละเอียดกัน ไม่น่าแปลกใจที่มีการเพิ่มประสิทธิภาพที่เรียกใช้สำหรับอาร์เรย์สเกลาร์ที่มีขนาดไม่เกิน 64 องค์ประกอบ การเพิ่มประสิทธิภาพเป็นส่วนหนึ่งของการวิเคราะห์การหลบหนี มันวางวัตถุขนาดเล็กและอาร์เรย์ขนาดเล็กลงบนสแต็กแทนที่จะจัดสรรไว้บนฮีปหรือแม้แต่ปรับให้เหมาะสมที่สุด คุณสามารถค้นหาข้อมูลบางอย่างเกี่ยวกับเรื่องนี้ได้ในบทความต่อไปนี้โดย Brian Goetz ที่เขียนในปี 2548:

• ตำนานการแสดงของเมืองมาเยือน: การจัดสรรเร็วกว่าที่คุณคิดและเร็วขึ้น

-XX:-DoEscapeAnalysisการเพิ่มประสิทธิภาพสามารถใช้งานกับตัวเลือกบรรทัดคำสั่ง ค่าเวทมนตร์ 64 สำหรับอาร์เรย์สเกลาร์ยังสามารถเปลี่ยนแปลงได้ในบรรทัดคำสั่ง หากคุณรันโปรแกรมของคุณดังต่อไปนี้จะไม่มีความแตกต่างระหว่างอาร์เรย์ที่มีองค์ประกอบ 64 และ 65:

java -XX:EliminateAllocationArraySizeLimit=65 Tests

ต้องบอกว่าฉันไม่แนะนำอย่างยิ่งที่จะใช้ตัวเลือกบรรทัดคำสั่งดังกล่าว ฉันสงสัยว่ามันสร้างความแตกต่างอย่างมากในแอพพลิเคชั่นจริง ฉันจะใช้มันก็ต่อเมื่อฉันมั่นใจในความจำเป็น - และไม่อิงตามผลลัพธ์ของเกณฑ์มาตรฐานหลอก

มีหลายวิธีที่อาจทำให้เกิดความแตกต่างขึ้นอยู่กับขนาดของวัตถุ

ตามที่ระบุไว้ nosid JITC อาจเป็น (ส่วนใหญ่คือ) จัดสรรอ็อบเจ็กต์ "local" ขนาดเล็กบนสแต็กและขนาดคัตออฟสำหรับอาร์เรย์ "เล็ก" อาจอยู่ที่ 64 องค์ประกอบ

การจัดสรรบนสแต็กนั้นเร็วกว่าการจัดสรรในฮีปอย่างมากและยิ่งไปกว่านั้นสแต็กไม่จำเป็นต้องเก็บขยะดังนั้นค่าโสหุ้ย GC จึงลดลงอย่างมาก (และสำหรับกรณีทดสอบนี้ค่าใช้จ่าย GC น่าจะเป็น 80-90% ของเวลาดำเนินการทั้งหมด)

นอกจากนี้เมื่อมีการจัดสรรค่าสแต็กแล้ว JITC สามารถดำเนินการ "กำจัดรหัสตาย" ได้ตรวจสอบว่าnewไม่เคยใช้ผลลัพธ์ของค่านี้ที่ใดและหลังจากมั่นใจว่าจะไม่มีผลข้างเคียงที่จะสูญหายให้กำจัดการnewดำเนินการทั้งหมดแล้วลูป (ตอนนี้ว่างเปล่า) เอง

แม้ว่า JITC จะไม่ทำการจัดสรรสแต็ก แต่ก็เป็นไปได้ทั้งหมดที่วัตถุที่มีขนาดเล็กกว่าขนาดที่กำหนดจะถูกจัดสรรในฮีปต่างกัน (เช่นจาก "ช่องว่าง" ที่แตกต่างกัน) มากกว่าวัตถุขนาดใหญ่ (โดยปกติสิ่งนี้จะไม่ทำให้เกิดความแตกต่างของเวลาอย่างมาก)