Click here for the FAQs on individual Auto* modules.

• What is the purpose of "New" in Config file preferences, and in the File menu, when you are initially setup with the necessary config files?

While the initial installation will set you up with config files, you have the ability to add more. For example, you can have multiple AutoNotes repositories with their own hotkeys, or in a company you could have a corporate-wide set of AutoTyper abbreviations in one autotyper file, but then individuals could have their own file. Or you could have some configs synched with Mobile Me, leaving others as specific to a particular machine. Most people will probably be happy with the initial config files provided.

• When I start Automaton I get a message "Cannot open file: /Users/home/Library/Application Support/Autoxxxxx/xxxxx.autoxxxxx. Persistent store migration failed, missing source managed object model" or "Can't find model for source store ~/Library/Application Support/Autoxxxxx/xxxxx.autoxxxxx".

  This shouldn't happen in normal operation, but it can happen if you go backwards in versions. Sometimes Automaton has to upgrade its data model rendering it incompatibile with older versions. Either make sure you are using the latest version, or if you must use an old version, restore the files compatible with the old version, or else recreate your config files in Preferences.

• Why does Automaton use so much memory?

  Actually, Automaton uses very little memory. I would estimate that in normal background use it probably uses little more than 5MB.

  You've got to be really cautious in interpreting memory usage stats.

  If you've got Growl 1.2 installed, which most people do, try this experiment: goto System Preferences, Growl configuration, and check "Show Growl icon in menu bar". Now look for "Growl Menu" in Activity Monitor. For me on Leopard Growl 1.2 (64 bit) shows 8 Gigabytes Virtual Memory (VSIZE) for this dinky little app, which all it can do is display that menu. On Snow Leopard, it shows 300MB which is twice as big as Automaton. Turn and on and off. Starts up pretty quick huh? Obviously it is not allocating 8GB of memory in less than one second.

  Real Memory (RSIZE) for Automaton on my OS-X 10.6 machine is usually about 17MB (running 64 bit), and 20MB on startup. Less than 10MB is Private (RPRVT), so the other half is shared with other processes. If I run it in 32 bit mode, the same result.

  On the 10.5 machine, it is saying 62MB when running in 32 bit mode, and doesn't go much below that. In 64 bit mode it can be reported as double that. You can go into Finder on 10.5 and do a Get Info on Automaton.app, and force it to run in 32 bit mode, and it will report less memory usage, but I have my doubts that the better statistics reflect any real gain.

  Since the exact same code is running in each case, either Apple have changed the way Activity Monitor counts it, or else Apple have made their libraries more efficient on Snow Leopard, or else Apple's code is better at clearing up unused memory on Snow Leopard. Since on Snow Leopard, Automaton in typical background use has about 17MB RSIZE, or which about half is probably private, and of that probably a good portion is the program itself, I'd say Automaton itself is only allocating at most about 5MB.

  Why is Automaton different to (some) other apps, especially running on 10.5? Well partly because it is 64bit, which Leopard seems to be exceedingly confused about reporting on. In short, Leopard Activity monitor can't be believed very much, especially for VSIZE. It may be partly due to the Automaton architecture which uses a number of small plugins, which probably also confuses the reporting in Activity Monitor.

  For example, right now I'm running Automaton 64 bit on Snow Leopard, and it says 183MB Virtual Memory (VSIZE). But the private memory is only 14MB. Shared Memory is 32.5MB. That means that Automaton is linked against Apple libraries that might be 183MB, little of which has, or ever will get into memory! All it means is these program pages *could* get into memory if the program ever asked for them. But a typical program only asks for certain features out of a large Apple library. The 32.5MB says that at least that much has got into memory, but it might not have been Automaton that did it! If Automaton is linked against Cocoa libraries, and say Finder is linked against the same library, it might have been Finder that caused that memory to get loaded!

  The Private Memory (RPRVT) truly belongs to Automaton, but even then it might not all be resident. Most programs will have only a small portion of their actual memory resident at once. How much memory the program demands as resident depends on how much it is "touching" at the time. Programs that have no windows open at the time typically aren't touching much. Programs that are inactive, or whose activity doesn't need much data aren't touching much. Its only active memory that really matters. For example, let's say you load an enormous document into AutoNotes, and then close it. Programs don't relinquish memory as far as Activity Monitor is concerned, but it gets paged out to disk, so your real memory isn't used. Yes, there is a "Real Mem (RSIZE)" column in Activity Monitor, but it includes shared libraries, so its not that helpful.

  In fact, a large Virtual Memory (VSIZE) in activity monitor, could actually indicate an efficient program. It means the program is using a lot of Apple libraries, (which are shared among different programs in memory), and not reinventing the wheel with code that can't be shared.

  At the end of the day, how much real memory is used is mostly to do with how much memory the program "touches" during normal background usage. And this should be very small indeed for Automaton. How much virtual memory is directly attributed to a program is the Private Memory (RPRVT) field. Normal users should ignore most of this stuff because it is too hard to interpret. The actual memory you are foregoing by running Automaton in normal background use is some number less than Private Memory, and less than (Real Memory - Shared memory), and has nothing whatsoever to do with Virtual Memory (VSIZE), which is entirely misleading.