[ https://issues.apache.org/jira/browse/LUCENE-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14067517#comment-14067517 ]
Robert Muir commented on LUCENE-5836: ------------------------------------- The problem is not unique to copyBytes. copyBytes/append/grow/copyChars are all stringbuffer-type methods. I really think we should remove/discourage these: because bytesref is *really crap* for a stringbuffer type object since it has no safety. You cant be a "reference to array with offset" and also be this: its just horrible software design!!!! > BytesRef.copyBytes and copyChars don't oversize > ----------------------------------------------- > > Key: LUCENE-5836 > URL: https://issues.apache.org/jira/browse/LUCENE-5836 > Project: Lucene - Core > Issue Type: Bug > Reporter: Adrien Grand > Assignee: Adrien Grand > > When copying data from another BytesRef/CharSequence, these methods don't > oversize. This is not an issue if this method is used only once per BytesRef > instance but I just reviewed the usage of these methods and they are very > frequently used in loops to do things like: > - keep track of the top values in comparators > - keep track of the previous terms in various loops over a terms enum > (lucene49 DV consumer, BlockTreeTermsWriter) > - etc. > Although unlikely, it might be possible to hit a worst-case and to resize the > underlying byte[] on every call to copyBytes? Should we oversize the > underlying array in these methods? -- This message was sent by Atlassian JIRA (v6.2#6252) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org