Because SAS Enterprise Guide is a .NET application, there are nuances to how memory is managed. You can't really tell too much about how efficient the application is simply by looking at the working set.
The .NET runtime is generous with initial memory allocations, if there are available resources. Over time, you might see memory use climb if you look at the working set number. But when resources get tighter on the system, you should see that number go back down.
For example, suppose that you start EG and open a large report. When the report is opened and rendered, you'll probably see memory use increase. When you close the report view, the application will free the memory, but you might not see the working set number decrease right away. That doesn't indicate a problem. It's only a problem if, over time as you use the application, memory use climbs and climbs and never goes down, even if your activity remains level.
One trick that sometimes works to show this: minimize the application and then restore it. You might see the working set go down. That's kind of like "jiggling the handle", but it doesn't really indicate a leak. It's just triggering Windows and the .NET runtime to clean up, which would have happened sooner or later.
There's an old article that describes this; it's out of date but mostly still applies:
http://www.getdotnetcode.com/gdncstore/free/Articles/The%20Memory%20Mystery.htm
Chris
