On Wed, Jan 13, 2010 at 09:43:12AM -0500, Yonik Seeley wrote:
> Yeah, something highly optimized for python in C may not be optimal for Java.
It looks like that algo was tuned to address poor reallocation performance
under Windows 9x.
http://svn.python.org/view/python/trunk/Objects/listobject.c?r1=19445&r2=20939
* This over-allocates proportional to the list size, making room
* for additional growth. The over-allocation is mild, but is
* enough to give linear-time amortized behavior over a long
* sequence of appends() in the presence of a poorly-performing
* system realloc() (which is a reality, e.g., across all flavors
* of Windows, with Win9x behavior being particularly bad -- and
* we've still got address space fragmentation problems on Win9x
* even with this scheme, although it requires much longer lists to
* provoke them than it used to).
*/
That "3" used to be a "1":
http://svn.python.org/view/python/trunk/Objects/listobject.c?r1=35279&r2=35280
> Seems like the right thing is highly dependent on the use case.
It seems that way to me. That's why I think it's better to have a simpler
routine and to force more responsibility onto the client code.
> In this case, the number of byte arrays temporarily being managed can
> be maxDoc (in the very worst case) so it's critical not to waste any
> space.
Yes, we want to make sure it's possible to ask for a specific array size and
get that exact array size. (I think this is a bigger problem in Lucy than in
Lucene, because we have to simulate bounded arrays with classes).
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
