Solr
  1. Solr
  2. SOLR-1707

Use google collections immutable collections instead of Collections.unmodifiable**

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Not a Problem
    • Affects Version/s: None
    • Fix Version/s: 3.3
    • Component/s: None
    • Labels:
      None

      Description

      google collections offer true immutability and more memory efficiency

      1. SOLR-1707.patch
        8 kB
        Noble Paul
      2. TestPerf.java
        2 kB
        Yonik Seeley

        Activity

        Hide
        Robert Muir added a comment -

        Bulk close for 3.3

        Show
        Robert Muir added a comment - Bulk close for 3.3
        Hide
        Noble Paul added a comment -

        This is a trivial issue

        Show
        Noble Paul added a comment - This is a trivial issue
        Hide
        David Smiley added a comment -

        (The priority of this issue should be trivial or at least minor, not major)
        Looking at the patch, it doesn't appear to be using Guava in performance-critical parts. I happen to like Guava API better, especially since it's updated for Java 5.

        Show
        David Smiley added a comment - (The priority of this issue should be trivial or at least minor, not major) Looking at the patch, it doesn't appear to be using Guava in performance-critical parts. I happen to like Guava API better, especially since it's updated for Java 5.
        Hide
        Robert Muir added a comment -

        Bulk move 3.2 -> 3.3

        Show
        Robert Muir added a comment - Bulk move 3.2 -> 3.3
        Hide
        Hoss Man added a comment -

        Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email...

        http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E

        Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed.

        A unique token for finding these 240 issues in the future: hossversioncleanup20100527

        Show
        Hoss Man added a comment - Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email... http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed. A unique token for finding these 240 issues in the future: hossversioncleanup20100527
        Hide
        Noble Paul added a comment -

        The discussion in guva list http://groups.google.com/group/guava-discuss/browse_thread/thread/23bc8fa5ae479698

        BTW What are the args passed for the Test

        keySize,numKeys, keysPerMap, numMaps, iter ?

        Show
        Noble Paul added a comment - The discussion in guva list http://groups.google.com/group/guava-discuss/browse_thread/thread/23bc8fa5ae479698 BTW What are the args passed for the Test keySize,numKeys, keysPerMap, numMaps, iter ?
        Hide
        Yonik Seeley added a comment -

        Here it is.
        To test for size, I cranked up the number of maps to 1M and then put the big sleep at the end of main, then used jconsole (hit GC a bunch of times in a row to see how low you can get the heap).

        Show
        Yonik Seeley added a comment - Here it is. To test for size, I cranked up the number of maps to 1M and then put the big sleep at the end of main, then used jconsole (hit GC a bunch of times in a row to see how low you can get the heap).
        Hide
        Noble Paul added a comment -

        yonik, could you share the test code?

        Show
        Noble Paul added a comment - yonik, could you share the test code?
        Hide
        Yonik Seeley added a comment -

        OK, I whipped up a quick test with String keys, many small maps (anywhere from 1 to 20 keys per map). Java6 -server 64 bit, Win7_x64

        Size:
        Collections.unmodifiableMap: 7.4% bigger than HashMap
        google immutable map: 22.4% bigger than HashMap

        Speed:
        Collections.unmodifiableMap: 4.2% slower than HashMap
        google immutable map: 26.0% slower than HashMap

        For best space and speed, looks like we should stick with straight HashMap.

        Show
        Yonik Seeley added a comment - OK, I whipped up a quick test with String keys, many small maps (anywhere from 1 to 20 keys per map). Java6 -server 64 bit, Win7_x64 Size: Collections.unmodifiableMap: 7.4% bigger than HashMap google immutable map: 22.4% bigger than HashMap Speed: Collections.unmodifiableMap: 4.2% slower than HashMap google immutable map: 26.0% slower than HashMap For best space and speed, looks like we should stick with straight HashMap.
        Hide
        Yonik Seeley added a comment -

        True immutability? What's that mean over Collections.unmodifiableMap()?
        And how do we know these are faster or more memory efficient?

        Show
        Yonik Seeley added a comment - True immutability? What's that mean over Collections.unmodifiableMap()? And how do we know these are faster or more memory efficient?

          People

          • Assignee:
            Noble Paul
            Reporter:
            Noble Paul
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development