Sunday, June 10, 2007 10:05 AMHey Guys please help me...........
Sunday, June 10, 2007 2:29 PM
Arrays tend to fixed in size, i.e. they can only contain a certain number of values. When you want to resize them then you need to recreate them which is normally done with the Redim statement but some languages don't allow arrays to be resized. Arrays are static in that they don't grow or shrink as you add/remove items from them.
Collections are dynamic in that they grow or shrink as you add and remove items from them.
Monday, June 11, 2007 9:31 AM
Arrays are a value type and collections are ref types.
Both allow sorting and you can get the number of elements in each very easily.
Arrays use less memory and tend to perform faster(not always) Colelctions are great to work with, so easy.
This articles sums it nicely
Monday, June 11, 2007 10:04 AM
Arrays are a value type and collections are ref types.
Hi, I'm sorry but I don't think that is true as you can have an array of reference types.
Monday, June 11, 2007 1:00 PM
Sincere apologies I'm so used to the structure vs class comparision
Arrays are also reference types (even if they have value types).
So Dim K(2) as string
K is still a reference type
Thursday, June 28, 2007 6:05 PM
I am programming in VB 2005 and really need to speed up my program. Until now I've been using
collections and dictionaries because of their "inteligence", but as a result - my program is really slow
My choice now:
1) If the collections with fix size are as fast as arrays I can limit the size of the collections
2) Rewrite almost all the program and use only arrays
3) Make my own class that would use arrays but have Remove and Add methods
What do you think is the best of those three?
thanks in advance,
Thursday, June 28, 2007 7:12 PM
It's your first post so it's ok but generally it's not recommended that you ask a new question at the end of another question, it's only encase someone else has a similar query and does a search. You may have called your post slow collections which someone could search for and they could read the recommendation. No sweat though.
Its very difficult to make a suggestion like this without knowing about whats being stored (types of object, or single type), the amount of data your storing (100,000 records), and how your accessing the collections (for example is boxing / unboxing happening).
Is very difficult. If your storing objects in your collection then boxing and unboxing could be happening, for example storing integers in a collection that stores types of object will slow things down. The integer needs to boxed into an object going into the collection and then unboxed to an integer when being accessed. If you access a collection like this in a loop it would be very slow.
Generic collections might help in this case.
Give me some more information on what your storing, how much your storing, and how your accessing whats stored. Could even be that a database approach might be better. Difficult to say without more information.
Friday, June 29, 2007 4:19 PM
Thanks Derek for your help
It’s true that I am new here, next time I will be more careful in where it is better to post my question. Hope you don't mind if I continue here
In short, my problem is - minimizing the cost of Flow (of product) in the Graph.
I use only classes for the Nodes, Products, Arcs ... Each Node have at least one Collection (of Product), same for the Arcs. The Graph consists of two Collections (Of Node), each Node keeps a Collection of outgoing Arcs.
I use only generic collections and always specify the type of the elements (so I don't have any boxing/unboxing). I don't specify the size of the collection because I don't know it in advance (only the upper bound)
In the algorithm I just go through the collection of smth and do smth. When I copy the Graph I copy the link to the Node and only create a new Collection of Products. That is why I concluded that the speed of my program depends on the speed of the Collection and the only alternative to the Collection I know is an Array.
If I understand it correct then
Both, Array and Collection - are reference type means that:
Lets say: Element is a Class, "e" is of type Element
So the line: Collection.Add( e ) will not create the copy of the "e" in the memory but put inside the reference to the "e"
same should be for the : Array( index) = e
If I pass an Array or a Collection by reference, as a parameter of the method/ function, then there will be no copy of the entire Array/Collection. I access the element by calling Collection.Item(e) , and I overread function Equals in the Class Element.
Now about the size:
In the big problem there are about 10000 nodes, 100 Products, which make the Graph to be:
Collection1 about 50 elements
Collection2 about 500 elements
Each Node has a collection of Arc from 100 to 1000 elements
If I set the size of the Collection in advance to the upper bound, then it is definitely better to use Arrays - no loosing time to search the Element - just working with the ID, no time loosing for increasing the size of the collection, but lots of unused space.
I can rewrite my program entirely by using Array instead of Collections. I have time and motivated to make my program as fast as possible, but it would be nice to know in advance that that would work.
Saturday, June 30, 2007 3:03 PM
I was doing a bit of research into this and found this line of text.....
Prefer Arrays to Collections Unless You Need Functionality
Arrays are the fastest of all collections, so unless you need special functionality, such
as dynamic extension of the collection, you should consider using arrays rather than
collections. Arrays also avoid the boxing and unboxing overhead.
This is from the Improving .NET Application Performance and Scalability patterns and design book (free download). In chapter 5 there are a couple of sections on arrays and collections including some guidelines and best practises.
I also have, at work, a book that details out some benchmarks for accessing array, if the above doesn't help I'll repost on tuesday what the book recommends.
Thursday, July 05, 2007 7:36 PM
Thanks a lot for the link,
this chapter was exactly what I've been searching for, I started to rewrite the programm already