I am making most of my basic types in my app, immutable. But should the collections be immutable too? To me, this seems like a huge overhead unless I am missing something.
I am talking about collections to hold Point3 values, etc which can be added as it goes at different times. So if there are 1M values in a collection, and you needed to delete 1 of them, you would have to create the same collection all over again, right?
It all depends on who is using the collections at the same time. Strings are immutable to prevent boo-boo's like two threads trying to remove the first char at the same time.
If you have a collection to which you can add items after constructing it, it is not immutable
A look up table would make for a decent immutable collection. It doesn't need to change in size and you want it static so it's quick to look up tricky calculations. If you need to add something later then I wouldn't bother with immutability, it defeats the purpose.
If you only ever add/remove from the start or end you might be able to cheat - but in general; yes: the implication is that you need to create a new collection for every change.
So: do you need to (effectively) mutate collections? If so, and given their size: I'd be tempted to look at synchronizing access (rather than making them properly immutable). Look at lock (aka Monitor).
My favorite trick with collections is simply to never pass them around. If they only exist inside a single object, then making them immutable is mostly irrelevant.
Usually your collection represents something right? It's a collection of dogs or a collection of invoices...
Usually there is a thing you can do with a collection of dogs (Herd? neuter?) or a collection of invoices (pay?) There are virtually always operations that apply to the whole list of objects--operations that have functionality beyond the singular invoice.pay() (for instance, ensuring that the most important invoices are paid first), without a class around your collection, there is really no where to put those operations.
It also usually makes sense to have a few variables associated with your collection--and again without a wrapper you always end up putting those variables in some strange unnatural location.
It may seem strange at first but try it a couple times before you judge.
Eric Lippert has a series on Immutability in C#, and if you read it all the way through he implements a couple different immutable collections:
It depends on the style your programm is written/designed.
Immutable collection do only make sense when you're programming in a functional-programming-influenced style (Imperatively designed programms shouldn't use them).
And like in functional languages, you should use Linked Lists then which can be built up in O(1) per element (cons) and process them functionally (recursions, building new lists from lists).
When your programm requires imperative collections (arrays, vectors/lists), keep them mutable.
I agree with Eric's comments about choosing the right tool for the problem. Immutability adds value when your goals include providing clear identity semantics, or making your implementation easier to work with in a parallel computing environment. Immutability can also help improve performance by allowing optimizations such as caching or transparent proxying.
On the flip-side, immutability can also incur a performance cost - particularly when you use the "copy-on-write" pattern to model "changes".
You have to decide why you want your entities/collections to be immutable - and that will help drive your decision of whether to do so or not.