From 88bffda5240731f38b0a2aeb6dbc088cf9fca60f Mon Sep 17 00:00:00 2001 From: Shawn Pearce Date: Wed, 12 Aug 2015 23:18:24 -0700 Subject: [PATCH] Bitmap builder: actually compress EWAH bitmaps in memory For construction performance each new EWAHBitmap is allocated at the roughly worst-case size the bitmap would need if all of the words must be literal and no run length compression is available. In practice this is far larger than is required, wasting heap memory while the bitmaps are computed. Trim down each bitmap to its minimum required size. This copies the internal array to a new smaller array, allowing the GC to reclaim the prior larger array for reuse. A single bitmap of 5.2M bits is only 79 KiB of memory without this trim call but 15,000 such bitmaps is 1.1 GiB. Trimming can help fit a larger number of bitmaps during processing. Change-Id: I2bd19a786189db5b01c4c96f209b83de50e10c3b --- .../jgit/internal/storage/file/PackBitmapIndexBuilder.java | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/org.eclipse.jgit/src/org/eclipse/jgit/internal/storage/file/PackBitmapIndexBuilder.java b/org.eclipse.jgit/src/org/eclipse/jgit/internal/storage/file/PackBitmapIndexBuilder.java index 05cd10095..62206c69c 100644 --- a/org.eclipse.jgit/src/org/eclipse/jgit/internal/storage/file/PackBitmapIndexBuilder.java +++ b/org.eclipse.jgit/src/org/eclipse/jgit/internal/storage/file/PackBitmapIndexBuilder.java @@ -115,6 +115,10 @@ public class PackBitmapIndexBuilder extends BasePackBitmapIndex { JGitText.get().badObjectType, String.valueOf(type))); } } + commits.trim(); + trees.trim(); + blobs.trim(); + tags.trim(); } private ObjectToPack[] sortByOffset(List entries) { @@ -168,6 +172,7 @@ public class PackBitmapIndexBuilder extends BasePackBitmapIndex { */ public void addBitmap( AnyObjectId objectId, EWAHCompressedBitmap bitmap, int flags) { + bitmap.trim(); StoredBitmap result = new StoredBitmap(objectId, bitmap, null, flags); getBitmaps().add(result); byAddOrder.add(result);