lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ning Li (JIRA)" <>
Subject [jira] Commented: (LUCENE-1035) Optional Buffer Pool to Improve Search Performance
Date Fri, 26 Oct 2007 14:27:51 GMT


Ning Li commented on LUCENE-1035:

> I don't think this is any better than the NIOFileCache directory I had already submitted.

Are you referring to LUCENE-414? I just read it and yes, it's similar to the MemoryLRUCache
part. Hopefully this is more general, not just for NioFile.

> It not really approved because the community felt that it did not offer much over the
standard OS file system cache.

Well, it shows it has its value in cases where you can achieve a reasonable hit ratio, right?
This is optional. An application can test with its query log first to see the hit ratio and
then decide whether to use a buffer pool and if so, how large.

> Optional Buffer Pool to Improve Search Performance
> --------------------------------------------------
>                 Key: LUCENE-1035
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Store
>            Reporter: Ning Li
>         Attachments: LUCENE-1035.patch
> Index in RAMDirectory provides better performance over that in FSDirectory.
> But many indexes cannot fit in memory or applications cannot afford to
> spend that much memory on index. On the other hand, because of locality,
> a reasonably sized buffer pool may provide good improvement over FSDirectory.
> This issue aims at providing such an optional buffer pool layer. In cases
> where it fits, i.e. a reasonable hit ratio can be achieved, it should provide
> a good improvement over FSDirectory.

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:
For additional commands, e-mail:

View raw message