alright then
First: if you doubt their work quantity, check their activity on github, not in pulls but in sheer amount of code, and at least double it for anything not XML
the amount of shit done is huge and everytime a mechanic is added it often becomes part of the shit to take into account when making anything new
I don't keep up to date on their commits, but i have previous experience modding the game's source code. My experiences with the code required i make 80 mindless edits/additions to add a custom race into the game. The amount of effort required to do simple things was unreasonable. The game isn't data drive which means quest text is stored in the EXE itself, which also bloats up the size. a lot of classes just have a brute forced Enum/switch statement combination. Unless you're suggesting the code has been streamlined and slimmed down, i'm not going to be impressed that code is getting added.
third: the performance issue i can't really say much but i've use jProfiler and it's really some html webengine stuff doing 60%+ of the time and it's a java thing, not the code.
I quite frank don't believe you, because my investigations years ago. When i checked the profiler, the majority of the slow down was caused by sending
strings into substring replace functions which would convert unformatted text, into HTML. basically replacing all instances of
\n with
<p></p>. This was handled on the developer side, not the library side. On small scale, this isn't a problem but given this is the main way text is displayed on the web engine and used constantly, it was the cause of the slowed down and needed to be optimized. Strings are not suppose to change, so if you "change" them, you have to make a new one, which is a waste of time/resources. There is a solution to this, called StringBuilder, which is a class type designed to be changed, and act like a string but this has a problem where you can't find and replace substrings without rolling your own solution or important a non-standard but common library (which she's already done before).
Then there's the way the code update pages. Lets take a massive resource hog like the inventory. Each time that inventory updates (assuming you have to the page open), the developer side code rewrites all the XML code, and passes it to the web engine. No, the XML generating code isn't anymore efficient than the HTML generating code. maybe the web engine is inefficient, and i haven't don't the research required to solve this issue myself, but you should be able to modify the XML passed in and tell the web engine to refresh the display, making the major resource hog the library.