Projects / fastutil

fastutil

fastutil extends the Java Collections Framework by providing type-specific maps, sets, lists, and queues for Java with a small memory footprint and fast access and insertion. It also provides big (64-bit) arrays, sets and lists, and fast, practical I/O classes for binary and text files.

Tags
Licenses
Operating Systems
Implementation

Recent releases

  •  28 Sep 2012 17:09

    Release Notes: In some very rare circumstances, enumeration of hash sets or maps combined with massive element removal (using the iterator remove() method) could have led to inconsistent enumeration. This has been fixed.

    •  24 Feb 2012 17:26

      Release Notes: Array-based priority queues now cache their first element, and fastutil can be found on Maven Central.

      •  10 Dec 2011 08:52

        Release Notes: More efficient radix sort methods.

        •  27 Sep 2011 10:09

          Release Notes: This release adds bugfixes in the TextIO.store() methods and rehashing of big sets.

          •  02 Sep 2011 19:40

            Release Notes: New methods for indirect queues. Doubly linked implementation for hash maps and sets. New array-based FIFO queues. A number of bugfixes.

            Recent comments

            17 Jun 2003 03:44 vigna

            Re: Library partitioning

            > Anything is better than the huge 15.3MB
            > jar. Since we'll be using webstart to
            > deploy our thin clients the extra 15MB
            > is definately not an option ;-P.


            However, you should look into AutoJar:

            http://www.rrz.uni-hamburg.de/RRZ/B.Eggink/en/javatools/autojar/

            which is written exactly to solve your problem!

            14 Jun 2003 08:12 Nipsu

            Re: Library partitioning

            > Well, I understand the problem, but it
            > is not that easy.
            >
            > My current plans for 3.0 (beside a
            > *fantastic* type-specific ArrayList
            > library 8^) include changing the
            > namespace to fastutil.int, fastutil.long
            > etc. At that point I could make some
            > separate jars. The problem is that then
            > you must include ALL those jars in your
            > path.
            >
            > Maybe separate jars with an option to
            > get a global jar is the best idea.
            > Comments are welcome...


            Anything is better than the huge 15.3MB jar. Since we'll be using webstart to deploy our thin clients the extra 15MB is definately not an option ;-P.

            Good to hear that you plan to add List support too! I had to write one myself since we also need to store loads of longs somewhere and just by using homemade specialized container saves memory + it performs much better. Long object = 12 + 8 bytes, long primitive 8 bytes. Makes big difference with big datas..

            If only Sun would have extended the upcoming generics to primitives also!

            11 Jun 2003 09:52 vigna

            Re: Library partitioning

            > Could you provide partitioned library in
            > the future? I benchmarked the


            Well, I understand the problem, but it is not that easy.

            My current plans for 3.0 (beside a *fantastic* type-specific ArrayList library 8^) include changing the namespace to fastutil.int, fastutil.long etc. At that point I could make some separate jars. The problem is that then you must include ALL those jars in your path.

            Maybe separate jars with an option to get a global jar is the best idea. Comments are welcome...

            04 Jun 2003 06:53 Nipsu

            Re: Library partitioning
            And BTW:
            Thx for the great library!

            04 Jun 2003 06:52 Nipsu

            Library partitioning
            Could you provide partitioned library in the future? I benchmarked the implementations for my application and found that the Long2ObjectAVLTreeMap was best for my needs. It took me three hours of testing, zipping and unzipping to extract only those classes that I needed (The original is huge 33MB jar and my modified jar is only 55KB)

            Another way is that you could somehow specify the required implementations in the build phase?

            Any comments?

            Screenshot

            Project Spotlight

            OpenStack4j

            A Fluent OpenStack client API for Java.

            Screenshot

            Project Spotlight

            TurnKey TWiki Appliance

            A TWiki appliance that is easy to use and lightweight.