lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2662) BytesHash
Date Tue, 28 Sep 2010 10:32:33 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915700#action_12915700
] 

Michael McCandless commented on LUCENE-2662:
--------------------------------------------

{quote}
bq. Maybe rename ords -> keys? And hash -> values? (The key isn't really an "ord" (I
think?) because it increases by more than 1 each time... it's more like an address since it
references an address in the byte-pool space).

yeah that depends how you see it - the array index really is the ord though. but I like those
names. I will change.
{quote}

Duh, I agree -- the new names are confusing!!  Sorry.  I was
confused... you are right that what's now called "keys" are in fact
really ords!  They are always incr'd by one, on adding a new one.

How about renaming key back to ord?  And then maybe rename values to
bytesStart?  And in their decls add comments saying they are indexed
by hash code?  And maybe rename addByOffset -> addByBytesStart?


  * On the nocommit in ByteBlockPool -- I think that's fine?  It's an
    internal class....

  * The nocommit in BytesRefHash seems wrong?  (Ie, compact is used
    internally)... though maybe we make it private if it's not used
    externally?

  * On the "nocommit factor this out!" in THPF.java... I agree, the
    postingsArray.textStarts should go away right?  Ie, it's a
    [wasteful] copy of what the BytesRefHash is already storing?

  * Can we impl BytesRefHash.bytesUsed as an AtomicLong (hmm maybe
    AtomicInt -- none of these classes can address > 2GB)?  Then the
    pool would add in blockSize every time it binds a new block.  That
    method (DW.bytesUsed) is called *alot* -- at least once on every
    addDoc.

  * I'm confused again -- when do we use RecyclingByteBlockAllocator
    from a single thread...?  Ie, why did the sync need to be
    conditional for this class, again....?  It seems like we always
    need it sync'd (both the main pool & per-doc pool need this)?  If
    so we can simplify and make these methods sync'd?
    


> BytesHash
> ---------
>
>                 Key: LUCENE-2662
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2662
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Index
>    Affects Versions: Realtime Branch, 4.0
>            Reporter: Jason Rutherglen
>            Assignee: Simon Willnauer
>            Priority: Minor
>             Fix For: Realtime Branch, 4.0
>
>         Attachments: LUCENE-2662.patch, LUCENE-2662.patch, LUCENE-2662.patch, LUCENE-2662.patch
>
>
> This issue will have the BytesHash separated out from LUCENE-2186

-- 
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message