[
https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801934#action_12801934
]
Paul Elschot commented on LUCENE-1410:
--------------------------------------
{quote}
In the first benchmark, I was not repeating the loop until 1 second is reached
since there is no easy way to "reset" the reader. In the new benchmark, I am
recreating the reader in the loop (which causes some overhead). Do you think it
can have a consequence on the JIT ?
{quote}
I don't know how wheather JIT deals with the code for invidual objects (other
than classes and their code). There could be an indirect effect via the garbage
collector.
The uniform random range of about 65000 generates almost always 14-16 bits per
number, so these results are roughly comparable to the 14-16 bit cases posted
on 6 October 2008 by Michael. As it happens they are quite close.
> 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-1410-codecs.tar.bz2,
> LUCENE-1410b.patch, LUCENE-1410c.patch, LUCENE-1410d.patch,
> LUCENE-1410e.patch, TermQueryTests.tgz, 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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
