[
https://issues.apache.org/jira/browse/LUCENE-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698886#action_12698886
]
Earwin Burrfoot commented on LUCENE-1604:
-----------------------------------------
Yep, that was my blunder. :)
bq. An alternate approach that would eliminate this overhead is to subclass the
scorers that use norms and create an appropriate scorer that doesn't require
the check. The drawback of this approach would be that it is harder to maintain.
Somebody recently raised a topic on specialized Lucene, with classes generated
from templates, hardwiring various choices. Guys at MG4J generate a custom
indexReader for each possible combination of index settings. So the idea of
separate scorers might be valid, if we're going optimization-freak way. (and we
don't have to support them separately)
By the way, why everything surrounding norms map is heavily synchronized? I
haven't found a single write to the map outside of initialize().
> Stop creating huge arrays to represent the absense of field norms
> -----------------------------------------------------------------
>
> Key: LUCENE-1604
> URL: https://issues.apache.org/jira/browse/LUCENE-1604
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Affects Versions: 2.9
> Reporter: Shon Vella
> Priority: Minor
> Fix For: 2.9
>
> Attachments: LUCENE-1604.patch
>
>
> Creating and keeping around huge arrays that hold a constant value is very
> inefficient both from a heap usage standpoint and from a localility of
> reference standpoint. It would be much more efficient to use null to
> represent a missing norms table.
--
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
