List/Array should handle another List/Array - Upgrade System - Performance

Hi, I am making an Idle Game where you can buy upgrades. (Mobile)

I have a List which stores the value if an Upgrade was bought. (bool) It is also saved in a savefile.

The second List stores my GameObjects.

On the Start of the game I want to Destroy Upgrades which are already bought, Disable all Upgrades which are not unlocked and Enable all unlocked Upgrades.

My Problem is now f.e.: If I add an Upgrade between Upgrade 1 and Upgrade 2 the new upgrade two acts as bought when I start the game because (obviously) they don’t have any connection besides the indexes. And it is pretty unhandy to use if i want to add new stuff.

How do I make a valid connection between does Lists?

My attempts

I could use a for loop to cycle both indexes but it requiers that both lists have the same indexes and it doesn’t work well if I add new stuff.

Problem:It is pretty unhandy, implementing new things doesn’t work well

I could use a foreeach loop of the bought list and inside another foreeach loop of the Gameobject List to handle the stuff. It requires a new value inside the bought list f.e. the name and search the name in the Gameobject lists to handle it.

Problem: I read that a foreeach loop is a lot slower than a for loop and it also has bad performance.

I could use linq to join thoses lists

i found this: c# - Join two list on a specified column - Stack Overflow

I could join them via linq so that I have only one list and then handle the stuff I need to do. If I would use this I would use it in the awake() function.

Problem: I have read, that linq has a very bad performance and I shouldn’t use it


I can choose a way which is pretty unhandy or a way which has a bad performance.

What should I do about it? Is there any way to do it in a better way. I’m also open to completely new Unlock Upgrade systems.

Thanks in Advance!

To be honest creating dependencies between lists via indexes is not very elegant coding. The very basic solution to this would be to keep track of the unlocked state from the upgrade class itself. When looking at it from an OOP perspective, an “unlocked” field/property for upgrades makes sense, as it is an inherent property of the abstract idea of an upgrade