Components are stored in sets, which are divided by class. Since we can have multiple sets loaded, we've got a map of sets, sorted by filename. Okay. So our megalith component-holding structure looks like this -
Now, this is an oversimplification, because each layer of that is wrapped in its own class with nice access functions, to make it easier.
That's just for the generic component tree. What about our handy objects to which we're adding these components to? Well, these are a little simpler - we've got a tree of hardpoints and components they're bound to, but we've also got an index of every hardpoint in the tree, sorted by the hardpoint name.
I hope you went 'wtf' at tree. Because I sure am whumping my head on the table at the moment, because I wrote my own datastructure. STUPID. STUPID. STUPID. I think this is probably the key source of my problem, because I never wrote methods to iterate through it. Well, not really. Its a mess.
Okay, now lets look back at the first megalith. Now... how are we supposed to iterate that? Well, the obvious answer is to say "Fuck it this is stupid lets think of a better way to do it", but noooo I'm too stupid to figure out that solution. What we're looking at is a triple-for loop for searching, yes! A TRIPLE FOR LOOP. Now, I'm not anti-loops or anything, but this just seems ridiculous.
Sigh. At this point, the stuff is pretty worked into the code, so it would be more work than its worth to uproot it and plant something better. Thankfully, none of this code will be used in the actual game portion, its just for the GUI crap which is fuckless performance intensive.
Premature pessimisation GO!!!
(haha, I love how a google search for "premature pessimisation" returns me as one of the top results...)