The way it computes the amount something takes on disk is basically by writing it into memory as if it were writing it to disk, and then seeing how many bytes that took. On top of that, the writing logic is validated when you open the save by immediately "writing" the whole save into memory, then comparing the result byte-by-byte with what was read from disk; if WarBender can't write your save out exactly like it read it, even if there's just a single byte difference, it's going to give you an warning and ask if you really want to open that save, given that you're likely to corrupt data if you then try to save it back. So I'm fairly confident that the numbers it gives are accurate.
That the app uses a lot of memory is also not surprising - it's rather profligate with it, on the basis that everybody has a lot of it these days.
Just to give one example, the aforementioned procedure to "write" data into memory is also used to validate any changes that you make to properties - i.e. every time you edit some property or slot, the
entire save is "written" into memory, validating all object references, collection sizes etc as it goes. To see this in action, try opening any faction, then opening its "relations" using the [...] button on the right side of value, then click "Add", and press "OK". You should get an error message. If validation wasn't there, you'd end up with a corrupt save, because every faction should have exactly as many entries in its relations as there are factions in total - no more and no less. There are a few other places where there are inter-related collections like that in the save, and all of them are checked.
The memory used for all this validation is then immediately discarded, so it's not really used. But since .NET is a garbage-collected runtime environment, in practice it's going to keep it around until it thinks it's low on memory - so it can show as using quite a bit, even though in practice most of that is ready to be garbage-collected. I was really, really paranoid about data corruption when writing that code (due to bad experiences with some save editors for other games ruining my saves), so this is the trade-off - it could be much faster and more lean memory-wise, but then if something goes wrong, you might end up with a broken save without noticing. For the same reason, there's no "Save", only "Save As", and even then it automatically backs up your save if you try to overwrite an existing file - and all backups have unique names, so it won't overwrite a backup, either. It also writes saves out by first writing them into a temporary file, then moving the old file (if any) to the temp directory, then moving the new file that it wrote into its proper place, then finally deleting the old file - so even if you did something crazy like pull the power cord while it was saving, you will have either the old save intact, or the new save intact, but you will never lose both.
The "Parent" and "Raw" properties is just a display bug for the slots collection that I've missed when I added SizeInBytes. They're computed properties that don't reflect anything on the disk - "Parent" is the object to which those slots belong, and "Raw" is the actual integer values for the slots - i.e. before they get interpreted as references to other entities, or flags. I think I'll actually keep "Raw" around, since it might be useful occasionally to be able to view the raw slot values as numbers - just add parens around it, so it'll be "(Raw)". And "Parent" shouldn't be visible at all. I'll fix both in the next release - thank you for reporting it! Either way, these things don't affect the byte count in any way, so don't worry about them
Now, as far as the problem with the size of your saves. That slots take up so much space is not surprising, if you have a lot per object - every slot is 8 bytes (64-bit integer), and then the length of the slots collection is itself 4 bytes (32-bit integer). So if you have 2k slots per item, then
each item is 16 kilobytes just for the slots alone. So, with 1819 items, that's 1819 * (4 + 2048 * 8 ) = 29809772 bytes, i.e. 28.5 megabytes - sounds like what you're seeing. So far as I can see, in Native, items don't have any slots at all, which is probably why items don't usually come up as space-consuming. So I think your mod is special in that regard because it has slots on items, and conventional wisdom might simply not apply here.
On the other hand, map tracks are stored as five 32-bit floating point numbers each - 3 floats for X/Y/Z coordinates, 1 for angle of the arrow, 1 for age of the track - plus one 32-bit integer for flags (not sure what it stores there exactly, but presumably part of that is the party ID? I'll need to research it some day), and they don't have slots. So one track is 6 * 4 = 24 bytes, and 5636 tracks is 5636 * 24 = 135264 bytes, or 132 kilobytes. Again, sounds like what you're seeing.
.
