Re: Vector efficiency
Christopher Smith wrote:
Eric Sosman <esosman@acm-dot-org.invalid> wrote in
news:cPmdne5stv1pBW7ZnZ2dnUVZ_rmdnZ2d@comcast.com:
Christopher Smith wrote:
Vector and array are different things, capable of different
operations. You'll have to specify the operations you have in
mind, and what measures of "efficiency" (memory, time, ...?) are
important.
Hi Eric and Patricia --
So I did run a test between the vector approach, where I used the vector
<float>.get(i) to retrieve each record versus aligning the data into an
array declared as float[], and noticed about 2x computational speed
improvement. I guess there are a number of step performing a look up with
vector has to do as opposed to simple addressing through an array.
I think you're still overlooking the fact that a Vector and
an array are different things. For example, you cannot insert
a float into a Vector. A bit of magic called "autoboxing" takes
your primitive float value, creates a Float object from it, and
it's the Float that actually gets inserted. It's not all *that*
expensive to create objects -- the people who write the JVM have
a strong incentive to keep the cost down -- but the amount of work
is certainly more than that involved in plunking a float value
into a float[] array. There's also the memory issue (c.f. another
recent thread you've been involved in): The float will occupy four
bytes of memory, period, while the Float will use additional memory
to represent its "objectness" in addition to the naked value.
That's not to say that float[] is necessarily the right answer.
Once you have created an array its size is forever fixed: you
cannot add and delete elements. (You can change the values stored
in existing elements, but that's a different matter.) If you make
a float[N] array and later discover that you need N+M values, your
only recourse is to create a new array and copy what's needed from
the old one. Vector takes care of this automatically. Even if it
does so by copying arrays behind the scenes and thus expends as much
work as if you had managed arrays manually, the convenience is not
to be sneezed at. Expenditure of computer time is not the only
criterion of worth; one should also think about the expenditure of
programmer time. (Which is a better use of your talents: writing
code to slosh arrays around, or thinking up creative ways to do the
analysis your problem requires?)
Finally, micro-benchmarks can be very tricky. Even in compiled
languages it has become harder and harder to write good ones: the
compilers' optimizers have grown more and more aggressive, and are
more apt to recognize and discard whole swathes of "useless" code.
`for (x=0; x<1000000; ++x) /* empty */ ;' may become `x = 1000000;'.
In semi-compiled, semi-interpreted, semi-JITted, garbage-collected
Java it is even more difficult to write a meaningful micro-benchmark.
Your result of "2x computational speed" is plausible, certainly, but
such measurements need to be viewed with a great deal of caution.
--
Eric Sosman
esosman@acm-dot-org.invalid