My designer's memory is quickly filling up, and eventually the designer becomes unresponsive and I have to end the process from the Task Manager. But there's a twist: It only does this when I am working on one specific view. Any other view works normally.
So I start the designer and see that my memory, down in the lower right, is about 200 to 250 MB, normal for startup. I open the problem view. Each time I click on a component, memory use jumps upward, usually 50 to 100MB, sometimes by as much as 200MB! And it never comes down. I leave it be, figuring garbage collection must kick in eventually, but it never does. I close the problem view, go work on a different view, and things work normally; memory goes up a little, down a little, but stays more or less the same. The massive memory chunks allocated to the problem view are never reclaimed.
Yes, I could allocate more memory to the designer, but I suspect that would just let it fill up even more memory before becoming unresponsive; and besides, clearly there is something about the specific view going on here that must be a fixable problem. None of my other views do this. The view is not materially different from anything I've made a hundred times before: It takes in a unique ID corresponding to a database record, calls the database using a named query when it receives it, and displays what it gets back in a bunch of labels. There are a few dropdowns and date pickers in there if the user wants to edit some of the fields. There is literally nothing strange about it, and yet, there must be. And it doesn't seem to have any negative impact when served on a browser client, it only kills the designer.
I figured out what the issue was--or at least, I figured out what I needed to change to stop the problem from happening. Why it worked exactly is beyond my skills. I'll lay it all out here in case it helps someone else.
A lot of fiddling around and restarting established some patterns to the problem. I started with what I knew: The memory filled and the designer died multiple times while I was writing scripts to handle events. There are a half-dozen components on the page that have event scripts attached to them, mostly buttons but also a checkbox.
If I right-clicked on those components and asked for their Events window, memory would suddenly jump by an average of about 150MB.
That memory was gone--whatever else I did in the designer after that, it would never be reclaimed. If I closed the problem view at that point, and moved to other views to do other work, the designer's memory would function normally except that the new "floor" of memory use was whatever value it had jumped to. So somewhere, memory was getting allocated and never de-allocated. Memory leak.
If I opened more Events windows on components on the problematic view, the "memory floor" would continue to rise until it just plain ran out and crashed.
I did not get memory jumps if I right-clicked a component that had no Event scripts set on it; there had to be at least one script to trigger the memory jump. Also, it didn't matter what the script said, it only had to exist. "a = 1" was enough of a script to trigger the jump.
I added a completely fresh button component to the view, and these patterns held. So the components I already had on the view were not corrupted somehow; there was something about their interaction with other components or the view itself that was making the memory jump. That's when I started looking more closely at the other components, the ones without event scripts at all.
The memory consumption of the problem view was just fine as long as all I did was select components. Left-click on something, left-click on something else, and so forth. Each component added to the consumed memory, but before long garbage collection would kick in and return the total to a baseline. Repeat as long as you like. Except . . .
One particular drop-down was pulling a lot of data to offer as options. How much? Like about 60,000 individual items, as it turned out (did not realize that when I wrote the query). Outside the designer (i.e., served up as a web page), this works fine; it takes a few moments for that component to load, sure, but it works. Inside the designer, though, This Was Not Fine. Selecting that particular drop-down instantly jumped memory upward by 500MB. (As an aside, that seems excessive. I mean, sure, a database call that retrieves and stores 60,000 items should consume a non-trivial amount of memory! But 500MB?! That suggests that each individual options item is consuming almost 10kB. Really?)
I changed the database query to drastically reduce the data going into the drop-down, and suddenly looking at the Event windows of the other controls didn't cause memory to jump anymore. The view now behaved normally.
So in summary, the memory leak had something to do with the interaction between the drop-down with the very large number of options and the components on the page that had event-handling scripts. Even if I never touched the drop-down in the designer, just opening those other components' Events windows caused something to happen behind the scenes that caused those windows to allocate and never release an awful lot of memory. Not at all obvious, but after enough trial and error, I got there.
Can you expand a little bit on what you mean by this? As in, it's a dropdown with an options array with 60,000 elements? Or where was this data actually being "held" in Perspective's property model? That'll help identify whatever's going wrong.