lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Ideas to refactor Filed
Date Tue, 11 Mar 2008 13:45:56 GMT

Hello!

Responses below:

eks dev wrote:

> Moin Moin Michael,
>
> for the first issue I have crated LUCENE-1217, and for the second  
> one I have some questions.
>
> if we maintain length and offset internally in Field than we have  
> one, imo, theoretical "legacy performance problem" as we need to
> create new byte[length] and copy in order to preserve compatibility  
> (users expect this method to return compact array with 0 offset)
> I am talking about.
> public byte[] binaryValue();

Actually, if offset==0 and dataLength==array.length, can't we return  
the array itself?  This way legacy apps, which will pass both these  
checks, would see tiny (because of these added checks) performance  
loss?  Also, in a search setting, where doc was created from stored  
fields, I think both those checks would be true as well (unless  
FieldsReader is changed to share byte[] arrays between fields).

I think we should then deprecate binaryValue() in favor of  
getBinaryValue()?

> would that be acceptable, it is very small penalty and there will  
> be a way to avoid it? Anyhow, if one is using
> public void setValue(byte[] value), it is to be expected that this  
> user allready has a reference to value.  This makes this
> question rather theoretical, no?
>
> we could than create new methods,  getOffset() getLength()  
> getBinaryValue() that enable full spectrum and replace all uses  
> that expect 0-offset array.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message