Posted some diagnostics here:
http://geophysics.kos.net/~ted/misc/TextMateMemoryIssue.zip
The memory consumption went from maybe 170 MB for the files I had open at the time to over 1 GB in the time a new version of the file I had open was being written out by the assembler. This file itself is approximately 6 MB at its full length.
A few other things to note. The memory footprint does not increase if you are viewing the beginning of the file at the time of writing the new version. You need to be somewhere in the middle or end of it to see the effect. The memory allocation starts to grow -- sometimes quite rapidly -- as the new file contents are getting written, but nothing seems to get released after it's done. Closing the file in TextMate, however, will release the memory.
Anyway, I wouldn't get too worked up over this. I should just add some script function to my bundle that launches the assembler after closing the listing and reopens it again later. Hmm.... :)
Ted
On Apr 28, 2015, at 11:00 AM, Allan Odgaard mailinglist@textmate.org wrote:
On 15 Apr 2015, at 1:28, Edward K. Chew wrote:
Thanks. I was thinking there is another possibility too. The assembler I use generates a listing file. It's possible I might have had that open in TextMate when I ran the assembler again which would overwrite the open file. Could that lead to some kind of racing condition maybe?
It shouldn’t, but there could be an issue where a file is appended to/overwritten faster than TextMate can reload it (the file monitoring and reload is an area that I would like to improve upon).
As for potential memory leaks, the best way to measure this is to run “leaks TextMate” in a terminal; when TextMate allocates memory, it goes via malloc(3) that allocates pages from the OS and manages these. So the amount of memory allocated from the OS (shown in Activity Monitor) will be higher than actal malloc’ed memory, as it’ll be rounded up to full page sizes, and while TextMate may free memory totalling more than a page, it might not be possible to give back a page to the OS due to fragmentation or allocator implementation details.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate