Merging mods to increase Performance!
Anach:
Quote from: Inge on 2010 January 04, 11:50:57
Grrr! :( Makes you wonder why it's there! Maybe those xmls were more important than we thought. And there was some "unknown" What happens if you remove them even for the bona fide stuff already in there?
The 0x000-lots-of-zeros... xml files were only included with hair as far as I found. I also didn't find them in any official .dbc files, so I assumed they were probably added by DABOOBs or TSR Workshop and weren't actualy needed. The unknown files could very well be something to do with it. However, the merged content works perfectly fine in the mods directory, as either .dbc or .package, with no crashes or other issues without those zero xmls.
Inge:
...but it's not proven that there is any advantage in making dbcs for the framework folders?
Anach:
Quote from: Inge on 2010 January 04, 13:10:43
...but it's not proven that there is any advantage in making dbcs for the framework folders?
None as far as my own testing has shown. I initially did .dbc, then renamed (later remerged) as .package, and saw no difference performance wise. As JM stated, they appear to be identical files, except for whatever the official launcher does to allow the game to recognise the .dbc when in the docs folder.
However, it certainly seems that the fewer .package files in your mods folder, the better your game runs. I originally went from over 700 total, to 20 merged and 45 tweaks which I left as single files for ease of frequent modification and updates. I later cut that down to 5 merged and 39 tweaks and noticed that my larger household was running a few frames quicker average. I'm hoping to cut that down further to 6 main merged .package and a couple essential separate files (such as awesome and other tweaks that arent merge friendly) to see if it improves further. I would imagine that after a certain point there would be very little noticeable difference in performance.
*edit* as expected, it doesnt seem ill be gaining anymore performance by decreasing the amount of .packages further. I tried reducing my 45 total to 12 total, and didn't see a difference. Most of those were xml, ini, dll , ui type mods, so I didn't really expect much of a change, as they are fairly small and light compared to objects, clothing, or hair type mods. So as a recommendation, i'd suggest everyone leave those types of mods outside of the merged mods, due to it not making any difference performance wise, that they usually updated a lot more frequently than other types of mods and not all types will play nicely in a single file.
Anach:
Quote from: Moryrie on 2010 January 04, 12:21:08
I combined mine, and didn't seem to have any issues... when I was doing so however, I made sure none of the 'unknowns' or anything with a bunch of 0s (anywhere that I could see since I wasn't sure which column you were referring to) were deleted. It worked well. My game lags a lot less than it had even though I'd been running it with less CC than it has now. (I was only keeping what my sims were actively wearing in game.. anything else went to a folder on my desktop until I needed/wanted it).
I sorted mine into 4 files. 'Objects', 'CAS', 'Hair', and 'Patterns'.
Thanks for the guide though.
The only files I manually removed from any of my merged mods were _xml (in the tag column) with resource keys of 0x00000000000000 (instance column). These only seemed to show in a few mods, and were my only conflicts that required manually merge (as alerted by s3pe). I haven't seen any negative effect of removing these, and I didn't find them in the official .dbcs, so I assumed they were created by the modding tools as some form of identification for those particular tools, but I really don't know at this stage.
cefwyn:
Assuming these xml files you refer to are the ones tagged 0x73E93EEB, I have also been removing them as according to http://www.simswiki.info/wiki.php?title=Sims_3:PackedFileTypes they are just manifest files used by the launcher(at least as far as whoever posted that information can tell). I've been finding those resources in all manner of clothing packages, though I think they may all be ones that were created with TSR Workshop and later converted to a .package. In hair packages I've also been finding a lot of redundant resources which appear to reference bone structures for that hair which I have also been removing and havn't noticed any issues yet. Also, for those xml files it may be safer to, rather then deleting them completely, increment the instance value by one and keeping them as I did find some store packages which had multiple instances of those files with different data stored in them (Though again this may only be needed by the launcher).
I probably should have posted something on this ages ago since when the patch broke the launcher I extracted all my sims3packs with delphy's multi-installer and after finding the game suddenly unplayable with all those package files I had merged most of them together into a single storecontent.package file and had been using that for a while without problems. It's not really too surprising that Sims 3 isn't geared towards reading hundreds of small files efficiently since the best practice amongst game engines for some time now has been to create a virtual file system and read everything from a single file to reduce hard-drive access calls to the operating system (Which are very slow on windows).
Depending on your hardware Sims 3 should run without any noticable performance hit as long as you have no more then about 50-60 package files. If you've got a nice fast SCSI drive you may even be able to play without a performance hit without merging any packages and having a few hundred sitting on your drive, but it's always a good idea to reduce the amount of work the OS needs to do and have as few packages as possible. I can't really say what the limit is for Sims 3 as the performance hit may not even be related to the hardware limitations, but based on my own experience programming virtual file systems, trying to access more then 100 files (I definitely had more then 100 files after converting all the arr'd store content to .package) in a program is almost certainly going to produce a drop in performance, and while the hardware may be fast enough to access 45 or 50 files without a noticable hit you really want to try to get that number as close to 1 as possible as it also reduces fragmentation(depending on file size and hardware) and can make the entire game engine run smoother.
Navigation
[0] Message Index
[#] Next page
[*] Previous page