I'm actually not after any performance improvements, just after convenience.
Like I said, today I have an awkward way to do clear(), instead I want to
add clear() which will do a simple fields.clear(). Since Document keeps an
ArrayList of fields, calling clear() on it is not that expensive (nulling
Compared to caching and passing in a List to the Document constructor,
I imagine a clear() based solution would be slower... there's more
work to do. clear() needs to null the pointers, and then one needs to
add the fields again, one-by-one. But I doubt we'd be able to detect
a variance anyway, g
I came across this while working on 1595 (changes to benchmark). I noticed
LineDocMaker reuses Document and Fields, and I wanted to pull that up to a
base DocMaker since I got the impression it yields better (even if not
significant) performance.
With the addition of the Field ctor which accepts a
On Wed, May 20, 2009 at 3:27 PM, Shai Erera wrote:
> I noticed Document does not have a clear() method, to remove all the Fields
> set on it.
Document's state is so simple (a List and a boost), reuse doesn't seem worth it.
What if, instead, we allowed the List to be passed into via Document's
con
I noticed Document does not have a clear() method, to remove all the Fields
set on it. If we want to encourage the reuse of Document and Field, I think
it's a required method. We do have remove* versions, but no clear().
BTW, I noticed that Field's constructors check for null value and throw an
ex
