Tips & Tricks: memory problems

by Giuseppe Lanzi on 12/02/2014

Sometimes programmers may not have anything to do with solving algorithmic problems, but need to solve problems related to using the application memory.

Sure, it’s always a problem of how the code is written, but compared to an algorithmic error that manifests immediately (sometimes even to the end user), a memory management error will only become apparent at a certain point, when things have gone too far and the server has used all the available memory. It’s an effect that can even occur very far from its cause.

In these cases we have to answer the question “where did I put all that memory?”. I’m writing this post today to offer some tips that seem simple, but that I’ve noticed are quite helpful.

First of all, it’s a good idea to use an effective tool for your analysis. Don’t just trust what Task Manager tells you, because it’s not a tool that was designed for this purpose. Task Manager simply informs you of the fact that a certain application is using a given amount of operating system memory, but it doesn’t tell you in which class it’s being used, and above all it doesn’t distinguish between memory that’s actually used by the application and what the web server is setting aside for itself because it knows it may need it.

To try run a test with this small example project on IIS and see what kind of tool I’m talking about, I recommend you try the demo for ANTS Memory Profiler, which I’ve found effective and helpful in a complex task like solving a memory leak.

Try opening New Form IMDB and looking at which classes the memory is being used in. You’ll find live instances of IMDBFldValue that correspond to 30,000 lines that I’ve inserted in an Instant Developer IMDB (In Memory Database) table.

Now close the form and then check the memory again. You’ll still have the same number of instances of IMDBFldValue still “alive” in memory. That’s because the IMDB tables are made expressly to be accessible from the entire application, and from this point of view they should be considered equal to a global variable. When you close New Form IMDB, the IMDB table it contains isn’t emptied. Instead, it’s kept in memory for possible reuse by other procedures in the application.

And this is where the second piece of advice comes in, for people who use Instant Developer. It’s common practice to empty IMDB tables immediately before filling them again. This typically happens when you open the screen, but if you use large IMDBs it could lead to memory problems if you don’t also empty the tables when the form closes by using the Unload event.

Try to uncomment the content of the event in the project and you’ll see the difference immediately.

Will you help me choose the next Tips & Tricks article?

  •    Managing multi-domain user/object synchronization
  •    Integrating JavaScript libraries into your offline applications
  •    Beyond an article on the blog: what we need is a Webinar on customizing graphics
Loading ... Loading ...

Leave a Comment

Previous post:

Next post: