Re: Parallel arrays revisited
On 10/12/2010 11:33 PM, Daniel Pitts wrote:
On 10/12/2010 8:27 PM, Lew wrote:
Eric Sosman wrote:
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 ...
There's good optimization (algorithmic) and bad optimization
(micro-managed). It's never too early for the first kind.
Never say never. If you have an enum class, and you want to create a
method which returns one instance by some property, the first approach
should be a for-loop+compare. Only if you find out this is inside a
tighter inner loop should you replace it with a map look up. (This exact
thing happened to me in a real world situation, actually).
Immutability is part of a toolkit of idioms to construct stable,
extensible systems that are inevitability about as fast as you can
safely get. It's especially handy for the large class of real-world
applications that are multi-threaded.
Good optimization of static initializers is structural rather than
cycles-based. You use static final initializers of immutable instances
to spread immutability. A special class of those are compile-time
constants, which have consequences for /happens-before/ relationships.
Initialization order matters, especially in enums. These optimize for
correctness, but properly done they do tend to make the program fast.
Remember, too, that there are different kinds of fast.
Also, const should be something in Java. I'm very sad it is not, given
the thread-safety it could bring.
Personally, I pine for immutable arrays. Even better, for
immutable "views" of mutable arrays. Yes, there's unmodifiableList(),
but I don't find it a truly happy-making alternative. For one thing,
its immutability is a run-time property, not something the compiler
can warn you about if you accidentally try a modification.
Your mention of enums calls to mind their wretched values() method,
which is forced to make a brand-new free-standing array object at
each call lest the caller scramble the contents of the real version.
If only the real version could be immutable, and hence safe to show
to the outside world ... Ah, well.
--
Eric Sosman
esosman@ieee-dot-org.invalid