On Fri, Jun 6, 2008 at 1:49 PM, Nils Kilden-Pedersen <
nilskp@...> wrote:
> On Fri, Jun 6, 2008 at 5:18 AM, David MacIver <
david.maciver@...>
> wrote:
>>
>> I'm not sure how to answer this question. I get confused by questions
>> of the form "Why do you do it this way? Couldn't you have done it a
>> more complicated way instead?"
>
> That's not the question. The question is "Why do you do it this way?
> Couldn't you have done it a more perfomant way instead?"
You've not made a convincing argument that it would be faster.
instanceof against a statically known type is fast: Hotspot is good at
dynamic type checks, and in particular is good at optimising them away
entirely. Checked type casts are all over the place and don't
noticably slow down the performance. x instanceof FinalClass should be
equivalent to x != null && x.getClass == classOf[FinalClass], which is
not an expensive operation.
I've not tried either approach yet. If the current approach for
testing really proves to be significantly faster then there's a more
convincing argument that it should be used. Even then it's not a clear
cut case - the version with instanceof has the nice property that a
strict object has the same memory footprint as a fully evaluated lazy
one. When you have something like Stream where there are a lot of lazy
nodes a word per node quickly adds up.
