Don't get me wrong, I do think they are needed, it's just been my
experience that it is fraught with traps. In Lucene, until we came up
w/ a more or less standard way of sharing algorithms (see contrib/
benchmark) it was always a bit hard to draw any real conclusion, b/c a
lot of it can depend on usage patterns, different JVMs on different
machines, etc.
Was just trying to say let's not worry too much about, but you both
are right, we should worry some :-)
-Grant
On Mar 14, 2008, at 11:15 AM, Jason Rennie wrote:
On Thu, Mar 13, 2008 at 3:15 AM, Isabel Drost <[EMAIL PROTECTED]
>
wrote:
Although it does pay to think about performance early if the goal
is a
library
that is to be used with large amounts of data. At the moment it is
still
easy
to try out different versions. I would guess it won't be that easy
once a
lot
code has been created...
+1
Optimizing the core aspects of a matrix library intended to scale
across
hundreds of machines is not what I'd call premature. It is well worth
understanding the tradeoffs here, as, yes, important decisions made
now
could be difficult to change later.
Btw, I yesterday learned how to determine the size of Java Objects
and was
quite surprised by the result:
http://javaquirks.blogspot.com/
Marginal storage cost of Integer/Float (16-24 bytes) is 4-6x larger
than
int/float (4 bytes). Double is 2-3x larger than double. Probably
worth
sticking to primitives if possible...
Jason
