-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve Garbage Collection #268
Comments
Thanks for reporting! Looks like there are two separate issues here:
|
* Update reach weap plugin (#259) * Fix reach weap plugin updates (#260) * Fix reach weap plugin updates * Fix spacing (whoops) * rename debugtools to addresstools also splits the convert button of both so usage is more clear * move tag information again now its in the tag editor * Update DataRef.cs * Some styling tweaks gets rid of padding in some areas * clear my backlog of plugin changes whats it been, a few years? also contains what I managed to port from h5 at the time, still unfinished lol and most of it didnt make it past h4 * update reach/mcc script xmls other games coming someday * add the new h2 plugins to the project oops * color field overhaul colorf now uses scRGB, integer-based colors all use color32 now, with color24 removed completely * Updated plugins to support previous color commit * rename a couple tag header things "important tags" to "global tags" and "polyart" to "tag interop" * rename stringid sets to namespaces * change writeascii to use latin encoding fixes an issue where regular ascii wouldnt preserve some of the odd characters found in stringids * remove h2 "head" plugin must have been a holdout from wherever the original h2v set came from * remove forced endianness in plugin generator * update h3 beta plugins i was trying to keep them separate for the h3b branch but meh * update plugineditor autocorrect for color * missed a spot on the tag header commit * rename reflexive to tagblock at last * replaced reflexive with tagblock plugins for the previous commit * correct typo in h2v layout * rename tag class to tag group if im gonna make big broad changes might as well do everything i can * rename bitfield to flags more stops on the proper names tour 2020 * replaced bitfield with flags plugins for previous commit * implement the previous 64bit flags also fixed the bits actually displaying properly * correct a nasty wrong name also some small things, one of which might not even matter but oh well * Actually kill off polyart includes renaming related things and providing some more info in the plugins * improve address tools tab can now convert to/from the contracted addresses within mcc tag data * Improve zoneset handling This should help with some injection issues * dataref improvements length and address boxes are no longer readonly and will update the content in realtime. unicode option removed because its not used in any plugins and likely isnt ever used period. #65 #263 * Add an allocator tool for datarefs Because manually changing sizes can be bad. * remove "meta" from ui dunno about all the code references * Clean up unused files Found some ghost files, also some images and dlls that aren't referenced/used anymore * simplify logo path data * Update forgotten element name refs * Swap unit boost recharge rate/delay in affected plugins #257 * dataref error protection prevents the combo of a nonzero length but invalid address horribly balooning the map file. * Update DataRefAllocator.xaml Forgot to change to button text. * finish adding datarefs to h2 plugins * correct scanned issues in plugins * update some plugins add in rectangle fields, fix up cutscene titles blocks * begin applying some of the new field types more basic/easy spots first * Add support for tooltips in plugins fields, bits, and enum options can use them, also adjusted related controls to better display them * increase buffer size on some stream copying stuff speeds up larger tag injections * Fix cusc sorting my backlog commit had the wrong block set for sorting * Big field control commit All fields "recreated" to use a similar grid layout instead of stackpanels. Previous tooltip commit toned down, only the name area will display the tooltip outside flags/enums, along with a bonobo-inspired indicator when one is present. MultiValue has been split up so it isn't such a pain to manage. Comment now hides its scrollviewer when there is nothing to display (bandaid for it eating scroll events). Tagrefs now use a default null group instead of a fake null group that would show errors in the output window. Degree no longer needs its own control. * Adjust left margin in tag editor Adding the tooltip indicator made things look off * Adjust treeview child margin * Update MetaEditor.xaml Uses rows instead of large margins * Move a particular object comment to a tooltip * Comment wasnt displaying the scrollbar * update all hlmt plugins * standardize damage reporting types a little * name some scnr stuff * make tag field textboxes invariant culture "Negative 'Infinity', I don't like it." ~Windows 10 * Show a validation tooltip on textboxes Also adjusts the exception for invalid pointers that displays. * mode-related plugins * small hud changes * more tooltip tweaks wrapping and max width, more info is displayed * Re-implement enum index option Now handled through binding, even updates in realtime too. * Add a quaternion converter * fix appveyor guess that isn't supported * Add more fields 64-bit number, 16-bit quaternion, and 16 bit point2, and adjust the quat converter to support 16-bit * Plugins using some of the new fields * Clarify licensing * More plugins big char stuff, touched up jmad, fixed some errors * Update WidthCalculator.cs how did i fuck this up so bad * add poking support for jan 29 update * some plugins * change inherited style for gear buttons tag block in particular the behavior didnt match the togglebutton next to it * try to reduce memory usage patch tab in particular #268 * Update mode.xml oops * Fix degree range fields #273 * support for todays update Co-authored-by: camden-smallwood <52939755+camden-smallwood@users.noreply.github.com> Co-authored-by: Lord-Zedd <Lord-Zedd@users.noreply.github.com> Co-authored-by: Aaron Dierking <aarond@fb.com>
Assembly's Blamite seems to suffer from poor garbage collection which leads to runaway memory leakage. This can primarily be seen when applying patches, and also when loading maps.
When starting Assembly, before loading in anything, it uses a measly 60 MB
Upon opening a
.asmp
patch file, the memory jumps up because it loads a bunch of data from the file. In this example, I am using Krevil's LNOS Corvette mod, which causes about a 500MB jump in Assembly.The above makes sense up until I apply the patch and close the tab in Assembly. After doing this, the memory raises further by about 40MB then drops very slightly once the patch is applied. However, overall there is a net gain in memory usage when patching.
Because I have applied the patch and closed the only open tab in Assembly, there should be a large drop in memory usage. The fact that there is not is indication of a major memory leak. Furthermore, this issue compounds. Leaving Assembly open, I restore the original map file I modified with the patch. Then I open up the same patch as before, apply it to the same map file, then close the tab again. This leads to Assembly hogging an entire gigabyte of memory.
This same behavior occurs on a smaller scale when opening and closing the same map file to view the tags. Though the memory increases are comparatively smaller each iteration, they all still stack on top of one another.
I came across this issue when using the Blamite DLL methods in my mod manager to add support for using assembly patch files. I can say for certain that this memory leakage is present in the Blamite project, though there are probably other places in Assembly that cause this same problem. I believe the cause might be the use of class wide variables which are never properly disposed of. They are used as globals in a sense, so that the data does not have to be passed into methods/classes. However I can't say I am extremely familiar with Assembly internals as I haven't spent much time inside the code.
Whatever is happening, this issue should be addressed as it can cause a computer to slow down considerably on machines with low RAM when doing heavy editing in Assembly across multiple files, especially when testing patches.
The text was updated successfully, but these errors were encountered: