[
https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637427#action_12637427
]
Michael McCandless commented on LUCENE-1410:
--------------------------------------------
bq. That means there is quite a bit of room for disk speeds to catch up with
CPU speed.
Exactly!
Search optimization is tricky because for an index that can't fit
entirely in the OS's IO cache, reducing the CPU cost of searching
(which we are diong, here) is basically usless: the end user won't see
much benefit.
For an index entirely in the IO cache, I think these optimizations
might make a big difference.
In some sense, we have been allowed to hide behind the slow
performance of magnetic hard drives and not worry much about reducing
the CPU cost of searching.
However: relatively soon most computers will use SSDs, and then
suddenly it's as if every index is in the IO cache (albeit a somewhat
slower one, but still far faster than magnetic media). So now is
the time for us to reduce the cpu cost of searching for Lucene.
And this means for this issue and other sources of optimizing search
performance, we should largely focus only on indices entirely cached
in the IO cache.
> PFOR implementation
> -------------------
>
> Key: LUCENE-1410
> URL: https://issues.apache.org/jira/browse/LUCENE-1410
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Other
> Reporter: Paul Elschot
> Priority: Minor
> Attachments: autogen.tgz, LUCENE-1410b.patch, TestPFor2.java,
> TestPFor2.java, TestPFor2.java
>
> Original Estimate: 21840h
> Remaining Estimate: 21840h
>
> Implementation of Patched Frame of Reference.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
