|
|
|
|
|
|
| Re: In the eclipse platform APIs or JDT and others, it seems that they use arrays as arguments or re [message #293099 is a reply to message #292699] |
Tue, 18 October 2005 08:31   |
Eclipse User |
|
|
|
Originally posted by: douglas.pollock.magma.ca
CL [dnoyeb] Gilbert wrote:
> No benefits. Arrays can still be improperly typed and don't offer
> immutability. I used to use them a lot but I changed to collections
> because there is really no advantage with arrays, unless they are
> extremely unlinely to change or are part of core classes that are used
> very frequently and in high number or instances
I'd like to share an anecdote. I used to use Collection instances for most
of the code relating to commands and key bindings. I then switched over to
using arrays. The switch gave me about 5-10% CPU improvement and about 20%
memory improvement.
I think the biggest gains are avoiding iterators and minimizing unused
space. These are not intrinsic problems with the Collections library, but
I feel they are encouraged by the nature of the API. Take, for example,
the copy constructor in ArrayList. It adds 10% of unused space to the end
of the copied ArrayList. An add that exceeds the size will throw 50% of
extra space on the end of the ArrayList. Most people would use this
without realizing this side effect. In general, we have more information
available about how the data will grow, and so can optimize how an array
will grow.
If an array is returned from an API, then the user can choose to use the
array as is, or use Arrays.asList to convert it to a collection.
cheers,
d.
|
|
|
|
|
| Re: In the eclipse platform APIs or JDT and others, it seems that they use arrays as arguments or re [message #293311 is a reply to message #293303] |
Thu, 20 October 2005 15:59 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
John Arthorne wrote:
> CL [dnoyeb] Gilbert wrote:
>
>> Yes, you can be sure of what it contains, but not of what you can put
>> into it. Collections are just the opposite. You can put anything
>> into them, but can't be sure of what you get out of them.
>>
>> Object [] x = new Integer[5];
>> x[0] = new String(""); //class cast exception
>>
>> Thats no advantage with respect to type safety to me. This is why we
>> needed Generics so desperately.
>
>
> That's a bit like saying if you declare all your fields and variables to
> be of type "Object" you don't get type safety. Well, that's true, but
> it doesn't mean it's not possibly to use more appropriate types to get
> the safety you need. A generic collection is no better than a typed
> array as far as type safety is concerned (with a lot of added
> syntactical gunk thrown in for good measure).
> --
Its nothing like using Object. An Object reference will always return
an instance that is a type Object. An Object reference will always
accept an instance that is of type Object. You can view arrays as not
behaving this way. Object []'s elements will always return an instance
that is a type Object. However, Object []'s elements will not accept an
instance just because it is of type Object.
There is a significant difference there. This knowledge is just the
opposite of Collection as stated previously.
Generic collection aleviate this issue. In fact it was generics that
first clued me in to the existance of this issue because of some
warnings from the compiler.
Object [] is fine for getting things out, but you have _no idea_ what
you can safely put into it.
CL
|
|
|
Powered by
FUDForum. Page generated in 0.04192 seconds
Home