Quote from: Spdskatr on May 27, 2017, 09:12:12 PMBeing somewhat of a necromancer, and you probably got your answer long ago already, for posteriority's sake:
So... Just putting this out there... If I were to use C# to replace the def after it was all loaded, would this way be the fastest? Compared to PatchOperations, I'm doing a targeted System.Collections.Generic.Dictionary search and then directly editing the fields with the same accuracy as a PatchOperation.
Yes, it would be the fastest approach. You are effectively operating in-memory on native objects, as opposed to in-memory representations of XML documents (which are somewhat more complex than one level deep lists or dictionaries). There is a caveat you have to remember though: patch operations are effectively preprocessing, whereas the objects you work with in C# (unless you hook into the core resolver) are ones that have already been resolved - inherited, overridden, so forth. During a patch, many defs with the same defNames can co-exist in the XML structure (each in a different mod package). After resolution there'll be at most one given def type with a given defName, so naturally its lookup will be faster.
But.
This effectively invalidates load order resolution on the XML level, because when you do that, everyone who wants to tweak your values further (be it in a public mod, or for their own personal use locally), is effectively forced by you to not only load in their modifications after your mod, you are also forcing them to write their own C# assembly and apply their changes there. So not only do they have to at the very least understand C# basics, they need to figure out your code, and then they also need to understand the lifecycle of game objects, hook calling order, and so on. Well, you get the picture
Also, this is (theoretically) a double-edged sword. If you wanted to remove a def from the database, it would be faster do to this in a patch than after resolution, because it prevents the removed node(s) from being resolved at all (they don't exist anymore once they arrive at the resolver for processing). If you were to do it programatically in C#, then you would be adding overhead by removing something that went through the whole patching-resolution process. Theoretically.
Practically, it depends on how heavy the mod load is, how many patches are getting applied to the values you're interested in (...). You'd have to benchmark on a case by case basis, which is not feasible. Which in turn means this pretty much falls into the micro-optimizations tantrum, and instead of worrying about performance, you should pick the most apparent, easiest to read solution. I'd argue patches are easy to read, especially for others, and even coding not-so-savvy players. As opposed to digging through, let alone decompiling, your code to find out what you are changing.