ไลบรารี Java Collections ที่มีประสิทธิภาพที่สุดคืออะไร [ปิด]

ไลบรารี Java Collections ที่มีประสิทธิภาพที่สุดคืออะไร

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

UPDATE:เพื่อชี้แจงฉันต้องการทราบว่าส่วนใหญ่ของไลบรารีที่จะใช้เมื่อฉันต้องเก็บรายการนับล้านไว้ในตารางแฮช ฯลฯ (ต้องการรันไทม์และหน่วยความจำขนาดเล็ก)

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

ส่วนตัว (และฉันลำเอียง) ฉันรัก Guava (รวมถึงโครงการ Google Java Collections เดิม) มันทำให้งานต่าง ๆ (รวมถึงคอลเลกชัน) ง่ายขึ้นมากในทางที่มีประสิทธิภาพอย่างน้อยสมเหตุสมผล เนื่องจากการดำเนินการรวบรวมข้อมูลไม่ค่อยก่อให้เกิดปัญหาคอขวดในรหัสของฉัน (จากประสบการณ์ของฉัน) นี่คือ "ดี" กว่า API การรวบรวมซึ่งอาจมีประสิทธิภาพมากกว่า แต่ไม่ได้ทำให้โค้ดของฉันอ่านง่าย

เนื่องจากการซ้อนทับกันระหว่าง Trove และ Guava นั้นเป็นศูนย์ที่ค่อนข้างมากบางทีคุณอาจจะอธิบายให้ชัดเจนว่าคุณกำลังมองหาอะไรจากห้องสมุดรวบรวม

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

ฉันแก้ไขเกณฑ์มาตรฐานจากtroveเพื่อวัดการใช้งานจริงและหน่วยความจำ ฉันยังเพิ่มPCJไปยังเกณฑ์มาตรฐานนี้ซึ่งเป็นอีกหนึ่งคอลเลกชันห้องสมุดสำหรับประเภทดั้งเดิม (ฉันใช้ที่หนึ่งอย่างกว้างขวาง) เกณฑ์มาตรฐาน 'ทางการ' ไม่ได้เปรียบเทียบ IntIntMaps กับ Java Collection ของการMap<Integer, Integer>เก็บIntegersและการจัดเก็บintsอาจไม่เหมือนกันจากมุมมองทางเทคนิค แต่ผู้ใช้อาจไม่ใส่ใจกับรายละเอียดทางเทคนิคนี้เขาต้องการจัดเก็บข้อมูลที่แสดงได้intsอย่างมีประสิทธิภาพ

ก่อนอื่นส่วนที่เกี่ยวข้องของรหัส:

new Operation() {

     private long usedMem() {
        System.gc();
        return Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
     }

     // trove
     public void ours() {
        long mem = usedMem();
        TIntIntHashMap ours = new TIntIntHashMap(SET_SIZE);
        for ( int i = dataset.size(); i-- > 0; ) {
           ours.put(i, i);
        }
        mem = usedMem() - mem;
        System.err.println("trove " + mem + " bytes");
        ours.clear();
     }

     public void pcj() {
        long mem = usedMem();
        IntKeyIntMap map = new IntKeyIntOpenHashMap(SET_SIZE);
        for ( int i = dataset.size(); i-- > 0; ) {
           map.put(i, i);
        }
        mem = usedMem() - mem;
        System.err.println("pcj " + mem + " bytes");
        map.clear();
     }

     // java collections
     public void theirs() {
        long mem = usedMem();
        Map<Integer, Integer> map = new HashMap<Integer, Integer>(SET_SIZE);
        for ( int i = dataset.size(); i-- > 0; ) {
           map.put(i, i);
        }
        mem = usedMem() - mem;
        System.err.println("java " + mem + " bytes");
        map.clear();
     }

ฉันถือว่าข้อมูลมาในรูปแบบดั้งเดิมintsซึ่งดูเหมือนว่ามีเหตุผล แต่สิ่งนี้แสดงถึงการลงโทษแบบรันไทม์สำหรับ java util เนื่องจาก auto-Boxing ซึ่งไม่จำเป็นสำหรับกรอบการรวบรวมแบบดั้งเดิม

ผลลัพธ์รันไทม์ (โดยไม่ต้องgc()เรียกใช้) บน WinXP, jdk1.6.0_10:

                      การดำเนินงานที่ใส่ได้ 100,000 การดำเนินการที่มีอยู่ 100,000 ครั้ง 
คอลเลกชัน java 1938 ms 203 ms
trove 234 ms 125 ms
pcj 516 ms 94 ms

แม้ว่าสิ่งนี้อาจดูรุนแรง แต่นี่ไม่ใช่เหตุผลที่จะใช้เฟรมเวิร์กดังกล่าว

เหตุผลก็คือประสิทธิภาพของหน่วยความจำ ผลลัพธ์ของแผนที่ที่มีintข้อมูล100,000 รายการ:

คอลเลกชัน java จะแกว่งระหว่าง 6644536 ถึง 7168840 ไบต์
trove 1853296 ไบต์
pcj 1866112 ไบต์

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

จากประสบการณ์ของฉันการใช้หน่วยความจำสูงเป็นปัญหาด้านประสิทธิภาพที่ใหญ่ที่สุดของ Java ซึ่งแน่นอนว่าส่งผลให้ประสิทธิภาพการทำงานของ runtime แย่ลงด้วยเช่นกัน กรอบการรวบรวมดั้งเดิมสามารถช่วยได้ที่นี่จริงๆ

ดังนั้น: ไม่ java.util ไม่ใช่คำตอบ และ "การเพิ่มฟังก์ชั่นการใช้งาน" ลงในคอลเล็กชัน Java ไม่ใช่ประเด็นเมื่อถามเกี่ยวกับประสิทธิภาพ นอกจากนี้คอลเล็กชั่น JDK ที่ทันสมัยก็ไม่ได้ "ทำผลงานได้ดีแม้แต่คอลเล็กชั่น Trove พิเศษ"

ข้อจำกัดความรับผิดชอบ: มาตรฐานที่นี่อยู่ไกลจากความสมบูรณ์และไม่สมบูรณ์แบบ มันมีความหมายที่จะขับรถกลับบ้านจุดที่ฉันมีประสบการณ์ในหลายโครงการ การรวบรวมดั้งเดิมมีประโยชน์เพียงพอที่จะทนต่อ API คาว - หากคุณทำงานกับข้อมูลจำนวนมาก

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

นี่คือการวิเคราะห์เสียงที่มากขึ้นในแง่ของกลไกมาตรฐานและห้องสมุดที่ครอบคลุม นี่คือเธรดในรายการ dev mahout

ห้องสมุดที่ครอบคลุมคือ

• HPPC
• ขุม
• FastUtil
• Mahout (เด็กผู้ชาย)
• Java Collections

อัปเดตมิถุนายน 2558 : น่าเสียดายที่มาตรฐานเดิมไม่สามารถใช้งานได้อีกต่อไปและนอกเหนือจากความล้าสมัยแล้ว นี่คือการเปรียบเทียบที่เป็นธรรม (ม.ค. 2558) ล่าสุดโดยบุคคลอื่น มันไม่ครอบคลุมและไม่มีเครื่องมือสำรวจเชิงโต้ตอบเช่นเดียวกับลิงก์ดั้งเดิม

ตามที่ผู้แสดงความเห็นคนอื่น ๆ ได้สังเกตเห็นคำจำกัดความของ "ประสิทธิภาพ" จะทำให้เกิดเครือข่ายที่กว้างขวาง อย่างไรก็ตามยังไม่มีใครพูดถึงห้องสมุด Javolutionห้องสมุด

ไฮไลท์บางส่วน:

• คลาส Javolution นั้นรวดเร็วเร็วมาก (เช่นการแทรก / การลบข้อความใน O [Log (n)] แทน O [n] สำหรับ StringBuffer / StringBuilder มาตรฐาน
• ชั้นเรียน Javolution ทั้งหมดนั้นใช้งานได้แบบเรียลไทม์และมีพฤติกรรมที่กำหนดไว้สูง นอกจากนี้ (แตกต่างจากไลบรารีมาตรฐาน), Javolution นั้นปลอดภัย RTSJ (ไม่มีการขัดแย้งของหน่วยความจำหรือหน่วยความจำรั่วเมื่อใช้กับส่วนขยาย Java Real-Time)
• คลาสของคอลเลกชันเรียลไทม์ของ Javolution (แผนที่, รายการ, ตารางและชุด) สามารถใช้แทนคลาสคอลเลกชันมาตรฐานส่วนใหญ่และมีฟังก์ชันเพิ่มเติม
• คอลเลกชัน Javolution จัดให้มีการรับรองพร้อมกันเพื่อให้การใช้อัลกอริทึมแบบขนานง่าย

การแจกแจง Javolution มีชุดมาตรฐานเพื่อให้คุณสามารถดูว่าชุดข้อมูลเหล่านี้ซ้อนทับกับไลบรารีอื่น / คอลเลกชันในตัวได้อย่างไร

บางคอลเล็กชัน libs ที่ต้องพิจารณา:

• คอลเลกชัน Java ใน java.util
• ขุม
• ห้องสมุดGoogle Collections
• Apache Commons Collections
• lib ระดับสูงจาก Cliff Click
• คอลเลกชัน Doug Lea lib - ไม่ได้รับการสนับสนุนอีกต่อไปและสร้างขึ้นใหม่ใน JDK

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

Google Collections น่าจะเป็นห้องสมุดคุณภาพสูงที่ดีที่สุดนอก JDK มันใช้งานหนักและรองรับได้ดี

Apache Commons Collections เก่ากว่าและทนทุกข์ทรมานจากปัญหา "พ่อครัวมากเกินไป" แต่ก็มีสิ่งที่มีประโยชน์มากมายเช่นกัน

Trove มีคอลเล็กชั่นพิเศษสำหรับกรณีเช่นคีย์ / ค่าดั้งเดิม ทุกวันนี้เราพบว่าใน JDK ที่ทันสมัยและด้วยคอลเลกชัน Java 5+ และกรณีการใช้งานพร้อมกันคอลเลกชัน JDK จะทำงานได้ดีแม้กระทั่งคอลเลกชันพิเศษของ Trove

หากคุณมีกรณีการใช้งานพร้อมกันที่สูงมากคุณควรตรวจสอบสิ่งต่างๆเช่น NonBlockingHashMap ใน lib ระดับสูงซึ่งเป็นการใช้งานแบบไม่ล็อคและสามารถใช้งาน ConcurrentHashMap ได้

java.util

ขออภัยสำหรับคำตอบที่ชัดเจน แต่สำหรับการใช้งานส่วนใหญ่Java Collectionsเริ่มต้นนั้นเพียงพอแล้ว

หากต้องการจัดเก็บStringแผนที่เป็นล้านๆ ลองดูที่http://code.google.com/p/flatmap

ฉันเป็นผู้พัฒนาคอลเล็คชั่นแฮปปี้จากคอลเลคชั่นแฮปปี้ที่ปลอม

1. การรวบรวมตามเหตุการณ์
2. unmodifiable
3. SortedList
4. ขุมทรัพย์

ConcurrentHashMap เช่นเดียวกับjava.util.concurrentแพคเกจควรจะกล่าวถึงถ้าคุณวางแผนที่จะใช้ HashMap ในหลายกระทู้ หน่วยความจำขนาดเล็กมีการพิจารณาเนื่องจากเป็นส่วนหนึ่งของจาวามาตรฐาน

ขึ้นอยู่กับวิธีที่เรากำหนด "มีประสิทธิภาพ"

โครงสร้างข้อมูลทุกตัวมีพฤติกรรม Big-Oh ของตัวเองสำหรับการอ่านการเขียนการวนซ้ำหน่วยความจำ ฯลฯ รายการที่เชื่อมโยงในไลบรารีหนึ่งมีแนวโน้มที่จะเหมือนกัน และแผนที่แฮชจะเร็วขึ้นสำหรับการอ่าน O (1) กว่ารายการที่เชื่อมโยง O (n)

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

สิ่งนี้ดูเหมือนจะไม่ "มีประสิทธิภาพมากที่สุด" ดูเหมือน "ยอดนิยม" สำหรับฉัน

แค่คำติชมบางอย่าง - ฉันไม่เคยได้ยินและไม่รู้จักใครที่เคยใช้ คอลเล็กชันที่สร้างขึ้นใน JDK, Google หรือ Apache Commons เป็นที่รู้จักกันดีสำหรับฉัน

ทรัวมีข้อได้เปรียบเล็กน้อย

• รอยเท้าหน่วยความจำขนาดเล็กมันไม่ได้ใช้ Map.Entry วัตถุ
• คุณสามารถใช้กลยุทธ์แฮชแทนปุ่มสำหรับแผนที่ซึ่งจะช่วยประหยัดหน่วยความจำและหมายความว่าคุณไม่จำเป็นต้องกำหนดคีย์ใหม่ทุกครั้งที่คุณต้องการแคชวัตถุในชุดคุณลักษณะใหม่
• มันมีประเภทคอลเลกชันดั้งเดิม
• คิดว่ามันมีตัววนซ้ำภายในบางรูปแบบ

ที่กล่าวมามีการดำเนินการหลายอย่างเพื่อปรับปรุงคอลเลกชัน jdk ตั้งแต่เขียนเป็นกอง

มันเป็นกลยุทธ์ที่คร่ำครวญที่ทำให้มันดึงดูดใจฉันแม้ว่า ... Google สำหรับขุมทรัพย์และอ่านภาพรวมของพวกเขา

หากคุณต้องการเก็บบันทึกนับล้านในตารางแฮชโอกาสที่คุณจะพบปัญหาหน่วยความจำ เรื่องนี้เกิดขึ้นกับฉันเมื่อฉันพยายามสร้างแผนที่ที่มีวัตถุ String 2.3 ล้านตัวอย่าง ฉันไปกับBerkeleyDBซึ่งเป็นผู้ใหญ่มากและทำงานได้ดี พวกเขามี Java API ที่ล้อมรอบ Collections API ดังนั้นคุณสามารถสร้างแผนที่ขนาดใหญ่โดยพลการด้วยหน่วยความจำน้อยมาก การเข้าถึงจะช้าลง (ตามที่จัดเก็บไว้ในดิสก์)

คำถามติดตามผล : มีห้องสมุดที่ดี (และมีประสิทธิภาพ) ได้รับการดูแลเป็นอย่างดีหรือไม่สำหรับคอลเลกชันที่ไม่เปลี่ยนรูปแบบ? Clojure ได้รับการสนับสนุนอย่างดีเยี่ยมในเรื่องนี้และมันคงจะดีถ้ามีบางอย่างที่คล้ายคลึงกับ Java