Indeed, upon next open the rules were loaded in about 10 seconds. Awesome! I underestimated your implementation, sorry!
I totally see how this can be a highly nontrivial issue. As the saying goes, there are three hard problems in software engineering: cache invalidation and off by one errors
15 minutes, and then 10 seconds cached is still too long, obviously
I still hope to be able to do something about it sometime.
Nevertheless, I think that with fast reload without edits this works quite well already. For example, if I need to make edits to one of these humongous files, I could batch them and don't reopen VS Code until I am done, then reload.
Good to hear. You could try to see how long saving a single file works. The moment you save is the moment it parses the file again. Differential parsing could help in this matter, but I'm not sure how to approach that (yet). The yaml library I use offers no such functionalities, I'd have to find something generic, or set it up myself.
Also, it is an argument for splitting these files into smaller ones (I do hope OXCE supports reading rules of one type from multiple files).
Yes, that is very possible. You can basically split things anyway you like (as far as I'm aware), and that would certainly help the problem. It's a workaround and it obviously doesn't directly address the core problem, but it will help.
I think your tool adoption would benefit from being more explicit about this caching. I think some people might give up before the 15 minutes for initial load are up. If the tool would somehow report how long it will take, and clarify it will be fast without edits, and reload only specific files upon edit, that would motivate people to give it a proper try.
I think the larger problem is that not too many people are aware of it, and secondly that people are quite content just using notepad++ for their modding. That said, I could drop it in the README somewhere. For most mods that I've tried it with, it's not really a problem though. It's the really large ones (there's only XCF, FMP and X-Piratez that are like that I think?) that are causing the long load times. There is something in my parser that does not scale, clearly