Re: Parallel arrays revisited
On 10/12/2010 3:56 PM, Joshua Cranmer wrote:
On 10/12/2010 02:55 PM, Tom Anderson wrote:
Clearly, Twitter's search is a case where it was worth expending
programmer time to save execution time. But parallel arrays are
definitely a technique which can save execution time.
Well, a fundamental lesson of programming is that you worry about this
kind of "microoptimization" (by which I mean the willful violation of
coding practices to eke out performance gains) only after you can
demonstrate it to be a performance bottleneck.
Microoptimization can be significant when macromagnified.
I think, in this case, the usage patterns can make a noticeable
difference in performance. I don't doubt that parallel arrays can save
execution time; however, I am hesitant to accept the claim that they
will save (significant) execution time in many/most/all cases.
They're primarily a memory-saving technique, secondarily a cache-
improvement technique (and then only for selected access patterns).
Since memory is a few hundred times slower than CPU's, such techniques
can make a significant difference -- but "can" is not "will", and
"difference" is not always in the desired direction.
So as always, leave the optimization until after its found to be a
problem. :-)
Ayeh. One recurring difficulty is that we as programmers are
woefully inclined to mis-measure "macro." Despite working with
systems that churn through terabytes in nanoseconds, we fall prey
to thinking "This loop might be executed a thousand times, ooh, wow,
a thousand; I'd better optimize it."
Now, if the loop runs its thousand iterations each time its
method is called, and if the method is called a thousand times each
time its bean is used, and if the bean is used a thousand times
a day on each of a thousand machines ... Sadly, though, I see
programmers (myself included!) diligently optimizing their static
initializers ...
--
Eric Sosman
esosman@ieee-dot-org.invalid