Panorama X memory usage


I’ve been running some performance tests on the lookupselected( function and, according to Activity Monitor, Panorama X uses an enormous amount of memory, even for what seem to me to be relatively modest tasks (but maybe they’re not). Here’s a screen shot of Activity Monitor towards the end of a test where 16,000 records were looking up 8,000. The two databases have identical content, so the number of comparisons will be the minimum possible. No other apps were open.

The tabulation shows Panorama X using 22 GB of memory while the display at the bottom shows that almost the whole of the 8 GB of RAM is being used. Several questions come to mind:

  1. Is the Activity Monitor reliable or meaningful?
  2. Does Panorama X swap in and out of RAM when it nears the limit?
  3. What is actually going into all that RAM - seriously 22 GB?


Not really.

Did the memory usage go down once the test was finished?

Panorama doesn’t do any explicit memory management, but the system does. We’ve come a long way from the bad old MacOS manual memory allocation days. Swapping is handled by the OS in close cooperation with special features in the Intel processor. It’s completely invisible to individual applications. In fact, applications don’t even know the real memory addresses of the memory they are using.

So the answer to your question is sort of yes – certainly memory could get swapped out. But this could happen with Panorama 6 on OS X also. Either way, the application itself isn’t even aware this is happening (if it is). That is all “behind the scenes”.

As Panorama performs a task, it is continuously allocating memory then releasing it. This is the nature of Objective-C, you can’t write an Objective-C program that doesn’t do that. But the memory isn’t released immediately (obviously, or why allocate it in the first place).

For contrast, right now I have quite a few web pages open in Safari. Activity monitor says that just ONE of those pages is using 1.46 Gb, and another is using 1 Gb. This is beyond Safari itself, which is using a half gig.

I notice that you aren’t displaying the Real Memory column. On my system, this value is often quite different than the Memory column, sometimes much smaller, sometimes much larger.

However, all this needs to be taken with a grain of salt. As I mentioned, Objective-C (and Swift) programs tend to perform thousands or even millions of memory allocations to perform a task. Panorama X is almost certainly doing millions of allocations to do your lookups. Most of these are probably tiny allocations, but they add up (and I think allocating 1 byte may count as a minimum of 1k or maybe even 16k). There are so many allocations, I’m pretty sure the system is not accurately tracking them for Activity Monitor because that would incur a huge performance penalty, especially if tracked on a second by second basis. So I’m pretty sure the numbers you see in Activity Monitor are approximations. As far as I know, there is no way for Panorama itself to determine it’s actual memory usage (I’ve looked, though I won’t 100% guarantee that I just didn’t find it).

It’s pretty hard to get OS X, or any modern operating system, to NOT use most of the physical RAM. It will try to keep the RAM as full as possible at all times. There’s no point in having empty RAM, so the OS X memory manager makes sure it is all in use if at all possible.



Thanks for all the other info. Altho I’m sure I’ll lie awake tonight wondering what the OS X memory manager finds to fill up the RAM :slight_smile:


It’s possible that there is some opportunity to improve Panorama in regard to short term memory usage during intensive tasks. There are a couple such tasks that release memory as they go, but most wait to release until the task is completely finished. In some cases I may be able to release some memory earlier. I’ve made a note to investigate this at some point in the future.

I’m not sure if this will make much difference, but it might for large databases with very large tasks. The task you are doing, a formulafill with a lookup( is probably a worst case as far as using temporary memory goes.