- Memory usage should be in the ballpark of starting footprint (40
MB) + file (66 MB) = 106 MB.
This is not possible because TM associates scopes with everything in your document and it also needs to create CoreText line objects to render the text (which is too slow to do ad-hoc so these are cached).
It will probably need 10-20 extra bytes per character in your document, which turns 66 MB into ~1 GB, add in memory fragmentation and data structure alignment requirements, and you probably have your 1.4 GB.
Maybe it can be improved, maybe there is the need for a special (limited) mode for large files, but it?s not currently a priority.
Thank you for the explanation. I really like TM2 for coding and was hoping it could be my editor for large files but it seems this was not meant to be-- will use TM for coding, vim for large files.
- After closing the window/file, memory footprint should go back to
near starting footprint (40 MB)
How do you measure this? The malloc allocator does not give pages back to the OS (AFAIK), so once a process has increased its number of allocated pages, the count does not go down again.
- Closing and reopening a file should not increase memory footprint
further.
This might be due to fragmentation. Here one solution could be a custom memory allocator to keep everything related to a document allocated from the same memory pool, but there are still many other things I would like to do, before I look into such optimizations.
I measured using the memory pane of Activity Monitor.app. Regarding the malloc allocator not giving pages back, this sounds bad behavior and is an OS or C library issue that should be fixed by "them." Thank you for taking the time to respond to my email.