You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2009/07/14 11:39:15 UTC
[jira] Created: (LUCENE-1743) MMapDirectory should only mmap large
files, small files should be opened using SimpleFS/NIOFS
MMapDirectory should only mmap large files, small files should be opened using SimpleFS/NIOFS
---------------------------------------------------------------------------------------------
Key: LUCENE-1743
URL: https://issues.apache.org/jira/browse/LUCENE-1743
Project: Lucene - Java
Issue Type: Improvement
Components: Store
Affects Versions: 2.9
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 3.1
This is a followup to LUCENE-1741:
Javadocs state (in FileChannel#map): "For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory."
MMapDirectory should get a user-configureable size parameter that is a lower limit for mmapping files. All files with a size<limit should be opened using a conventional IndexInput from SimpleFS or NIO (another configuration option for the fallback?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1743) MMapDirectory should only mmap
large files, small files should be opened using SimpleFS/NIOFS
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731091#action_12731091 ]
Michael McCandless commented on LUCENE-1743:
--------------------------------------------
At a minimum we should make FileSwitchDirectory friendly for subclassing, eg so you can override the currently private getDirectory method to implement your own custom logic. Hmm... we should somehow pass the "context" (at least 'read' vs 'write') to getDirectory() as well...
> MMapDirectory should only mmap large files, small files should be opened using SimpleFS/NIOFS
> ---------------------------------------------------------------------------------------------
>
> Key: LUCENE-1743
> URL: https://issues.apache.org/jira/browse/LUCENE-1743
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 3.1
>
>
> This is a followup to LUCENE-1741:
> Javadocs state (in FileChannel#map): "For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory."
> MMapDirectory should get a user-configureable size parameter that is a lower limit for mmapping files. All files with a size<limit should be opened using a conventional IndexInput from SimpleFS or NIO (another configuration option for the fallback?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1743) MMapDirectory should only mmap
large files, small files should be opened using SimpleFS/NIOFS
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731118#action_12731118 ]
Uwe Schindler commented on LUCENE-1743:
---------------------------------------
Another idea to think about:
Maybe we make the base FSDirectory configureable, that you can define rules for the IndexInput or IndexOutput instances used. Why create three directories, when you could only use on that just decides, what is the right IndexInput/IndexOutput? In this case you need no MMapDirectory, no NIOFSDir, no SimpleFSDir. The basic list files, rename and so on are always identical (for FSDirs). The only difference is the IndexInput and IndexOutput.
In this case you would only have *one* LockFactory, which would be good in my opinion (see above).
So we only provide the Input/Output classes as separate top-level classes: SimpleFSIndexInput, MMapIndexInput (internal two classes for chunking or not), NIOIndexInput and for output at the beginning only the current SimpleFSIndexOutput. You can then configure your FSDirectory to use different impls depending on an method or rule defined like above. For backwards compatibility, the current MMapDirectory and so on are simple subclasses of this universal FSDir with a fixed configuration.
FileSwitchDirectory should only used, when you really want to separate two directories in complete (stored fields on disk, index on SSD in two physical different dirs).
> MMapDirectory should only mmap large files, small files should be opened using SimpleFS/NIOFS
> ---------------------------------------------------------------------------------------------
>
> Key: LUCENE-1743
> URL: https://issues.apache.org/jira/browse/LUCENE-1743
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 3.1
>
>
> This is a followup to LUCENE-1741:
> Javadocs state (in FileChannel#map): "For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory."
> MMapDirectory should get a user-configureable size parameter that is a lower limit for mmapping files. All files with a size<limit should be opened using a conventional IndexInput from SimpleFS or NIO (another configuration option for the fallback?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Issue Comment Edited: (LUCENE-1743) MMapDirectory should
only mmap large files, small files should be opened using SimpleFS/NIOFS
Posted by "Earwin Burrfoot (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731632#action_12731632 ]
Earwin Burrfoot edited comment on LUCENE-1743 at 7/15/09 12:14 PM:
-------------------------------------------------------------------
The initial motive for the issue seems wrong to me.
bq. "For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory."
It is probably right if you're doing a single read through the file. If you're opening/mapping it and do thousands of repeated reads, mmap would be superior, because after initial mapping it's just a memory access VS system call for file.read().
Add: In case you're not doing repeated reads, and just read these small files once from time to time, you can totally neglect speed difference between mmap and fopen. At least it doesn't warrant increased complexity.
was (Author: earwin):
The initial motive for the issue seems wrong to me.
bq. "For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory."
It is probably right if you're doing a single read through the file. If you're opening/mapping it and do thousands of repeated reads, mmap would be superior, because after initial mapping it's just a memory access VS system call for file.read().
> MMapDirectory should only mmap large files, small files should be opened using SimpleFS/NIOFS
> ---------------------------------------------------------------------------------------------
>
> Key: LUCENE-1743
> URL: https://issues.apache.org/jira/browse/LUCENE-1743
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 3.1
>
>
> This is a followup to LUCENE-1741:
> Javadocs state (in FileChannel#map): "For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory."
> MMapDirectory should get a user-configureable size parameter that is a lower limit for mmapping files. All files with a size<limit should be opened using a conventional IndexInput from SimpleFS or NIO (another configuration option for the fallback?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1743) MMapDirectory should only mmap
large files, small files should be opened using SimpleFS/NIOFS
Posted by "Earwin Burrfoot (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731639#action_12731639 ]
Earwin Burrfoot commented on LUCENE-1743:
-----------------------------------------
bq. My problem was more with all these small files like segments_XXXX and segments.gen or *.del files. They are small and only used one time.
I can only reiterate my point. These files aren't opened like 10k files per second, so your win is going to be in the order of microseconds per reopen - at the cost of increased complexity.
> MMapDirectory should only mmap large files, small files should be opened using SimpleFS/NIOFS
> ---------------------------------------------------------------------------------------------
>
> Key: LUCENE-1743
> URL: https://issues.apache.org/jira/browse/LUCENE-1743
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 3.1
>
>
> This is a followup to LUCENE-1741:
> Javadocs state (in FileChannel#map): "For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory."
> MMapDirectory should get a user-configureable size parameter that is a lower limit for mmapping files. All files with a size<limit should be opened using a conventional IndexInput from SimpleFS or NIO (another configuration option for the fallback?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1743) MMapDirectory should only mmap
large files, small files should be opened using SimpleFS/NIOFS
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731638#action_12731638 ]
Uwe Schindler commented on LUCENE-1743:
---------------------------------------
A typical example, where MMap would be the wrong thing are e.g. norms. They are read one time and then the file is not accessed anymore. It would only be cool, if MMapDir could directly return the mapped array (but MappedByteBuffer.array() does not work) and use it as norms array. That would be cool.
My problem was more with all these small files like segments_XXXX and segments.gen or *.del files. They are small and only used one time. Mapping them is just waste of resources and completely useless (even slower that opening them directly). This is why I said, some limit or file extension based mapping would be good.
> MMapDirectory should only mmap large files, small files should be opened using SimpleFS/NIOFS
> ---------------------------------------------------------------------------------------------
>
> Key: LUCENE-1743
> URL: https://issues.apache.org/jira/browse/LUCENE-1743
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 3.1
>
>
> This is a followup to LUCENE-1741:
> Javadocs state (in FileChannel#map): "For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory."
> MMapDirectory should get a user-configureable size parameter that is a lower limit for mmapping files. All files with a size<limit should be opened using a conventional IndexInput from SimpleFS or NIO (another configuration option for the fallback?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1743) MMapDirectory should only mmap
large files, small files should be opened using SimpleFS/NIOFS
Posted by "Earwin Burrfoot (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731632#action_12731632 ]
Earwin Burrfoot commented on LUCENE-1743:
-----------------------------------------
The initial motive for the issue seems wrong to me.
bq. "For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory."
It is probably right if you're doing a single read through the file. If you're opening/mapping it and do thousands of repeated reads, mmap would be superior, because after initial mapping it's just a memory access VS system call for file.read().
> MMapDirectory should only mmap large files, small files should be opened using SimpleFS/NIOFS
> ---------------------------------------------------------------------------------------------
>
> Key: LUCENE-1743
> URL: https://issues.apache.org/jira/browse/LUCENE-1743
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 3.1
>
>
> This is a followup to LUCENE-1741:
> Javadocs state (in FileChannel#map): "For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory."
> MMapDirectory should get a user-configureable size parameter that is a lower limit for mmapping files. All files with a size<limit should be opened using a conventional IndexInput from SimpleFS or NIO (another configuration option for the fallback?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1743) MMapDirectory should only mmap
large files, small files should be opened using SimpleFS/NIOFS
Posted by "Eks Dev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731085#action_12731085 ]
Eks Dev commented on LUCENE-1743:
---------------------------------
indeed! obvious idea,
the only thing I do not like with it is making these hidden, deceptive decisions "I said I want MMapDirectory and someone else decided something else for me"... it does not matter if we have conses here now, it may change tomorrow
probably better way would be to turbo charge FileSwitchDirectory with sexy parametrization options,
MMapDirectory <- F(fileExtension, minSize, maxSize) // If <fileExtension> and file size less than <maxSize> and greater than <minSize> than open file with MMapDirectory... than go on on next rule... (can be designed upside down as well... changes nothing in idea)
the same for RAMDir, NIO, FS...
With this, we can make UwesBestOfMMapDirectoryFor32BitOSs (your proposal here) or
HighlyConcurentForWindows64WithTermDictionaryInRamAndStoredFieldsOnDiskDirectory just for me :)
So the most of the end users take some smart defaults we provide in core, and freaks (Expert users in official lingo :) have their job easy, just to configure TurboChargedFileSwitchDirectory
Should be easy to come up with clean design for these "Concrete Directory selection rules" by keeping concrete Directories "pure"
Cheers, Eks
> MMapDirectory should only mmap large files, small files should be opened using SimpleFS/NIOFS
> ---------------------------------------------------------------------------------------------
>
> Key: LUCENE-1743
> URL: https://issues.apache.org/jira/browse/LUCENE-1743
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 3.1
>
>
> This is a followup to LUCENE-1741:
> Javadocs state (in FileChannel#map): "For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory."
> MMapDirectory should get a user-configureable size parameter that is a lower limit for mmapping files. All files with a size<limit should be opened using a conventional IndexInput from SimpleFS or NIO (another configuration option for the fallback?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Issue Comment Edited: (LUCENE-1743) MMapDirectory should
only mmap large files, small files should be opened using SimpleFS/NIOFS
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731101#action_12731101 ]
Uwe Schindler edited comment on LUCENE-1743 at 7/14/09 1:21 PM:
----------------------------------------------------------------
bq. HighlyConcurentForWindows64WithTermDictionaryInRamAndStoredFieldsOnDiskDirectory just for me
By the way, for MMapDirectory the MappedByteBuffer.load() method should be somehow accesible/configureable to create this TermDictionaryInRam part (IndexInput would call load() and tells the OS to swap as much as possible of the mmaped file into RAM). Just an idea.
The Hyper FileSwitchDirectory was my idea yesterday, too. As Mike said, at least the getDirectory() should be configureable.
And for some good defaults, a factory could be provided like getUwesBestOfMMapDirectoryFor32BitOSs(File, LockFactory). What I do not like with the current FileSwitchDir is the fact, that you must create instances with the same Dir and LockFactory for each sub-directory (e.g. what happens if you use 2 different LockFactories on the same physical dir inside a FileSwitchDir?). Maybe the FileSwitchDirectory could just get the File and LockFactory once and creates the instances? Many ideas...
was (Author: thetaphi):
bq. HighlyConcurentForWindows64WithTermDictionaryInRamAndStoredFieldsOnDiskDirectory just for me
By the way, for MMapDirectory the MappedByteBuffer.load() method should be somehow accesible/configureable to create this TermDictionaryInRam part (IndexInput would call load() and tells the OS to swap as much as possible of the mmaped file into RAM). Just an idea.
The Hyper FileSwitchDirectory was my idea yesterday, too. As Mike that, at least the getDirectory() should be configureable.
And for some good defaults, a factory could be provided like getUwesBestOfMMapDirectoryFor32BitOSs(File, LockFactory). What I do not like with the current FileSwitchDir is the fact, that you must create instances with the same Dir and LockFactory for each sub-directory (e.g. what happens if you use 2 different LockFactories on the same physical dir inside a FileSwitchDir?). Maybe the FileSwitchDirectory could just get the File and LockFactory once and creates the instances? Many ideas...
> MMapDirectory should only mmap large files, small files should be opened using SimpleFS/NIOFS
> ---------------------------------------------------------------------------------------------
>
> Key: LUCENE-1743
> URL: https://issues.apache.org/jira/browse/LUCENE-1743
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 3.1
>
>
> This is a followup to LUCENE-1741:
> Javadocs state (in FileChannel#map): "For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory."
> MMapDirectory should get a user-configureable size parameter that is a lower limit for mmapping files. All files with a size<limit should be opened using a conventional IndexInput from SimpleFS or NIO (another configuration option for the fallback?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1743) MMapDirectory should only mmap
large files, small files should be opened using SimpleFS/NIOFS
Posted by "Eks Dev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731104#action_12731104 ]
Eks Dev commented on LUCENE-1743:
---------------------------------
right, it is not everything about reading index, you have to write it as well...
why not making it an abstract class with
abstract Directory getDirectory(String file, int minSize, int maxSize, String [read/write/append], String context);
String getName(); // for logging
What do you understand under "context"? Something along the lines /Give me directory for "segment merges", "read only" for search./
...Maybe one day we will have possibility not to kill OS cache by merging,
> MMapDirectory should only mmap large files, small files should be opened using SimpleFS/NIOFS
> ---------------------------------------------------------------------------------------------
>
> Key: LUCENE-1743
> URL: https://issues.apache.org/jira/browse/LUCENE-1743
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 3.1
>
>
> This is a followup to LUCENE-1741:
> Javadocs state (in FileChannel#map): "For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory."
> MMapDirectory should get a user-configureable size parameter that is a lower limit for mmapping files. All files with a size<limit should be opened using a conventional IndexInput from SimpleFS or NIO (another configuration option for the fallback?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1743) MMapDirectory should only mmap
large files, small files should be opened using SimpleFS/NIOFS
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731101#action_12731101 ]
Uwe Schindler commented on LUCENE-1743:
---------------------------------------
bq. HighlyConcurentForWindows64WithTermDictionaryInRamAndStoredFieldsOnDiskDirectory just for me
By the way, for MMapDirectory the MappedByteBuffer.load() method should be somehow accesible/configureable to create this TermDictionaryInRam part (IndexInput would call load() and tells the OS to swap as much as possible of the mmaped file into RAM). Just an idea.
The Hyper FileSwitchDirectory was my idea yesterday, too. As Mike that, at least the getDirectory() should be configureable.
And for some good defaults, a factory could be provided like getUwesBestOfMMapDirectoryFor32BitOSs(File, LockFactory). What I do not like with the current FileSwitchDir is the fact, that you must create instances with the same Dir and LockFactory for each sub-directory (e.g. what happens if you use 2 different LockFactories on the same physical dir inside a FileSwitchDir?). Maybe the FileSwitchDirectory could just get the File and LockFactory once and creates the instances? Many ideas...
> MMapDirectory should only mmap large files, small files should be opened using SimpleFS/NIOFS
> ---------------------------------------------------------------------------------------------
>
> Key: LUCENE-1743
> URL: https://issues.apache.org/jira/browse/LUCENE-1743
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 3.1
>
>
> This is a followup to LUCENE-1741:
> Javadocs state (in FileChannel#map): "For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory."
> MMapDirectory should get a user-configureable size parameter that is a lower limit for mmapping files. All files with a size<limit should be opened using a conventional IndexInput from SimpleFS or NIO (another configuration option for the fallback?).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org