Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Tue, 14 Jun 2011 08:12:47 +0000 (UTC)
From: "Uwe Schindler (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <107455020.2035.1308039167481.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <900178347.461.1308004787294.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (LUCENE-3200) Cleanup MMapDirectory to use only
 one MMapIndexInput impl with mapping sized of powers of 2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/LUCENE-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Uwe Schindler updated LUCENE-3200:
----------------------------------

    Attachment: LUCENE-3200.patch

Little cleanups & improvements:
- made readByte() consistent with readBytes() [catch block using remaining-while loop for size=0 buffers]
- renamed field names and variables to use chunkSize consistently

I think it's ready to commit, we should only wait for Mike to check on beast.

> Cleanup MMapDirectory to use only one MMapIndexInput impl with mapping sized of powers of 2
> -------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-3200
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3200
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>         Attachments: LUCENE-3200.patch, LUCENE-3200.patch, LUCENE-3200.patch, LUCENE-3200.patch, LUCENE-3200.patch, LUCENE-3200_tests.patch
>
>
> Robert and me discussed a little bit after Mike's investigations, that using SingleMMapIndexinput together with MultiMMapIndexInput leads to hotspot slowdowns sometimes.
> We had the following ideas:
> - MultiMMapIndexInput is almost as fast as SingleMMapIndexInput, as the switching between buffer boundaries is done in exception catch blocks. So normal code path is always the same like for Single*
> - Only the seek method uses strange calculations (the modulo is totally bogus, it could be simply: int bufOffset = (int) (pos % maxBufSize); - very strange way of calculating modulo in the original code)
> - Because of speed we suggest to no longer use arbitrary buffer sizes. We should pass only the power of 2 to the indexinput as size. All calculations in seek and anywhere else would be simple bit shifts and AND operations (the and masks for the modulo can be calculated in the ctor like NumericUtils does when calculating precisionSteps).
> - the maximum buffer size will now be 2^30, not 2^31-1. But thats not an issue at all. In my opinion, a buffer size of 2^31-1 is stupid in all cases, as it will no longer fit page boundaries and mmapping gets harder for the O/S.
> We will provide a patch with those cleanups.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org