{"id":2471,"date":"2012-11-28T06:54:57","date_gmt":"2012-11-28T14:54:57","guid":{"rendered":"http:\/\/manytricks.com\/blog\/?p=2471"},"modified":"2015-09-06T07:00:35","modified_gmt":"2015-09-06T14:00:35","slug":"witch-and-ram-usage-both-real-and-not-so-real","status":"publish","type":"post","link":"https:\/\/manytricks.com\/blog\/?p=2471","title":{"rendered":"Witch and RAM usage, both real and not so real"},"content":{"rendered":"

Witch<\/a>, our window switching application, is designed to be always-running (what good is a window switcher if it’s not active?). The program itself exists as two components: the user interface, where you modify Witch’s settings, and the background process that watches for the Witch activation keystrokes and builds the list when activated. The background process is named witchdaemon<\/tt>, and some users have emailed us with concerns about the RAM usage of this background daemon.<\/p>\n

The emails we receive come in two flavors:<\/p>\n

    \n
  1. Why is Witch using so much real RAM?<\/li>\n
  2. Why is Witch reserving gigabytes of virtual memory (VSIZE<\/tt> in top<\/tt>)?<\/li>\n<\/ol>\n

    Read on for the details on both real and virtual RAM usage by Witch\u2014the explanations are somewhat detailed and technical (especially relative to virtual memory), so put on your geek glasses before proceeding.<\/p>\n

    <\/p>\n

    High real RAM usage<\/h3>\n

    I’ll address real RAM usage first, because it’s both more important and much simpler to understand. To see how much real RAM Witch is using, run Activity Monitor (in Applications > Utilities), click on the Process Name header, and find witchdaemon<\/tt> in the list of processes. Here’s how it looks on my Mac:<\/p>\n

    \"The<\/a><\/div>\n

    The column of interest is Real Mem<\/b>, and as you can see, it’s only 13.4MB—and the daemon had been running for nine days when I took that screenshot. On your Mac, though, you may see a much different value, and it could be substantially higher; I’ve had reports of RAM usage exceeding 1GB. So why the differences? There are three things that affect the memory usage for witchdaemon<\/tt>:<\/p>\n

      \n
    1. The number of windows you’re switching between. Keep more windows open, and generally speaking, witchdaemon<\/tt> will use more RAM.<\/li>\n
    2. The setting of the “Show” pop-up menu in the Appearance tab of Witch’s settings. Set it to ‘application icons’ for the least memory usage; using ‘mini window previews if possible’ will use the most RAM.<\/li>\n
    3. Using window previews, either via the “Pop up a preview of the selected window after a” pop-up menu (also on the Appearance tab of Witch’s settings), or by pressing the Space Bar with a window selected. Show lots of window previews, and RAM usage will increase.<\/li>\n<\/ol>\n

      The reason these last two options use RAM is that Witch caches the images, so that future redraws of the panel will be quicker. For instance, here’s my same nine-days-running witchdaemon<\/tt> after I used a slew of window previews:<\/p>\n

      \"After<\/a><\/div>\n

      At present, this cache isn’t cleared aggressively by Witch, though the system will take it if it needs it. Over time, if you use preview icons and\/or window previews, you may see witchdaemon<\/tt>‘s memory usage increase. (The system will do some cleanup; my RAM usage fell to 92MB within a minute or so of taking the screenshot.)<\/p>\n

      The easiest way to reclaim this memory is to simply open the Witch settings panel<\/b>\u2014this will restart witchdaemon<\/tt> automatically, and thereby clear the cached image data.<\/p>\n

      High virtual memory usage<\/h3>\n

      If you’re the type of user who likes to really see the nitty gritty on what your machine is up to, you may occasionally use top<\/tt> in Terminal. top<\/tt> is basically like Activity Monitor, but for command line geeks. If you do, and you use Witch<\/a>, it may freak you out just a bit when you see something like this:<\/p>\n

      \"Output<\/a><\/p>\n

      Why on Earth would witchdaemon<\/tt> need 11 gigabytes<\/b> of VSIZE<\/tt>, whatever that might be? (In Activity Monitor, you can see these VSIZE<\/tt> values, but you must first select a process, then click Inspect; the value is on the Memory tab.)<\/p>\n

      Regardless of what it VSIZE<\/tt> may be, though, the sheer size of the number is shocking, and probably has you thinking “Geez, Witch is a huge memory hog; that’s horrible!”<\/p>\n

      As it turns out that this huge figure in VSIZE<\/tt> is nothing to worry about<\/b>, and it’s not exclusive to Witch. So if you’ve seen it, and wonder if you should care, the answer is you shouldn’t.<\/p>\n

      If you’re curious as to why<\/em> you shouldn’t care, then keep reading. (Things are going to get a bit geeky from here on out, so consider yourself warned.)<\/p>\n

      You’re headed into a maze of twisty little passages, all alike…at least, that’s how I feel when I start discussing OS X and memory management. In short, it’s a very complex and powerful system that generally works very well, but can be really confusing at times. Keep in mind I’m not a programmer (Peter is our founder and programmer) or memory expert, so the following is a semi-educated amateur’s attempt at explaining Witch’s huge VSIZE<\/tt> number, and why you shouldn’t care about it.<\/p>\n

      The VSIZE<\/tt> column represents the amount of memory ‘marked’ for an application’s potential use. The important bit is that it’s not reserved, protected, or otherwise used; it’s simply marked, as in “Witch may need 11GB of RAM at some point.” <\/p>\n

      If you look at the VSIZE<\/tt> figures in total, they can be shockingly large. If you look at my screenshot above, there’s a summary at the top; one of the lines summarizes the virtual memory situation:<\/p>\n

      <\/p>\n

      That 308GB of VSIZE<\/tt> reflects the memory that has been marked as possibly required for my currently running apps—yikes! But the reality is that this amount of memory will never be used or needed. Even more important is that application authors don’t control this VSIZE<\/tt> figure; the system does it itself, based on what the author’s code needs to do. So why is it so big? The honest answer is that I don’t know why, nor seemingly does anyone out there, at least based on some internet searches.<\/p>\n

      You can, however, see exactly what’s in that huge VSIZE<\/tt> space by using the vmmap<\/tt> tool. Enter this command in Terminal:<\/p>\n

      vmmap -resident `ps ax | grep [w]itchd | cut -b 1-5` | grep \"Summary for\" -A 999<\/pre>\n
      That looks complicated, but what it does is run vmmap<\/tt> on the process ID of witchdaemon<\/tt>, and then displays only the summary portion of the output (as there are thousands of lines). The output on my machine is as follows:<\/p>\n
      \n
      ==== Summary for process 66301\r\nReadOnly portion of Libraries: Total=143.7M resident=80.9M(56%) swapped_out_or_unallocated=62.7M(44%)\r\nWritable regions: Total=8.4G written=7248K(0%) resident=30.0M(0%) swapped_out=0K(0%) unallocated=8.4G(100%)\r\n\r\nREGION TYPE                      VIRTUAL RESIDENT\r\n===========                      ======= ========\r\nCG backing stores                  9100K    5824K\r\nCG raster data                      228K     192K\r\nCG shared images                   1280K    1256K\r\nCoreGraphics                         16K       8K\r\nCoreServices                       6232K    6232K\r\nIOKit (reserved)                  256.0M       0K        reserved VM address space (unallocated)<\/span>\r\nMALLOC                            337.2M    6520K        see MALLOC ZONE table below\r\nMALLOC (reserved)                   7.8G       0K        reserved VM address space (unallocated)<\/span>\r\nMALLOC freed, no zone              72.0M     196K\r\nMALLOC guard page                   104K       0K\r\nMALLOC metadata                     740K     260K\r\nMemory tag=240                        4K       4K\r\nMemory tag=242                       12K      12K\r\nMemory tag=243                        4K       4K\r\nSTACK GUARD                        56.0M       0K<\/span>\r\nStack                              9752K     116K\r\nVM_ALLOCATE                        16.2M    16.1M\r\n__DATA                             12.1M    9808K\r\n__IMAGE                            1240K     344K\r\n__LINKEDIT                         36.8M    10.9M\r\n__RC_CAMERAS                        248K       0K\r\n__TEXT                            106.9M    70.0M\r\n__UNICODE                           536K     456K\r\nmapped file                        23.3M    8492K\r\nshared memory                     135.8M   111.6M\r\n===========                      ======= ========\r\nTOTAL                               8.8G   247.4M\r\nTOTAL, minus reserved VM space    825.0M   247.4M\r\n\r\n                                          VIRTUAL   RESIDENT ALLOCATION      BYTES\r\nMALLOC ZONE                                  SIZE       SIZE      COUNT  ALLOCATED  % FULL\r\n===========                               =======  =========  =========  =========  ======\r\nauto_zone_0x100263000                      256.2M      4240K      17546      1698K      0%\r\nDefaultMallocZone_0x1001d0000               72.0M      2168K       7793      1597K      2%\r\nDispatchContinuations_0x10026c000           8192K        96K          1         32      0%\r\nenviron_0x100202000                         1024K        12K          1         16      0%\r\nDefaultPurgeableMallocZone_0x1007d6000         4K         4K          0         0K      0%\r\n===========                               =======  =========  =========  =========  ======\r\nTOTAL                                      337.2M      6520K      25341      3296K      0%<\/pre>\n<\/div>\n
      This command shows you the breakdown between what’s marked (VIRTUAL<\/tt>) and what’s being more actively used (RESIDENT<\/tt>). The lines I highlighted in red show three items that take no RESIDENT<\/tt> RAM, but have huge VIRTUAL<\/tt> values. Add them up, and of the 8.8GB in total VSIZE<\/tt>, roughly 8.1GB of it is taken up by things that aren’t using any RAM—and that aren’t controlled by Witch.<\/p>\n
      The RESIDENT<\/tt> column shows Witch using 247MB of RAM, but that doesn’t seem to be accurate either. To me, the best summary of Witch’s actual memory usage is found in the Inspect panel in Activity Monitor; here’s what it looked like while writing this blog entry:<\/p>\n
      <\/p>\n
      Here you can see that the witchdaemon<\/tt> process is using only 20MB of real memory, has 163MB of shared memory (used for inter-application communication, as I understand it), and has 7MB of private memory. (We are rapidly approaching the limits of my knowledge of OS X’s memory management system, so I’ll stop now!)<\/p>\n
      In summary, Witch’s VSIZE<\/tt> figure is high. But it’s nothing we’re doing to create it ourselves, and it’s not something we can reduce. The biggest chunk of it, the 7.8GB for MALLOC (reserved)<\/tt>, isn’t anything we can remove, as it’s the OS that’s putting it there. Why is it putting it there? Who knows. But here are a couple of related articles that show it’s not a Witch problem:<\/p>\n