Tuesday, March 22, 2011

Plugging IDE Memory Leaks

During the development of Real Studio 2011r1, we spent some time analyzing the compiler's memory usage. What we noticed was that the compiler was leaking memory. A memory leak occurs when code uses memory but then does not release this memory when it’s finished with it. The result is that the amount of memory the application uses continues to increase until the user quits the application or the application uses up all available memory and crashes.

During the development of 2011r1 we fixed every memory leak in the compiler. In fact, we went beyond that and fixed every leak we could find in the IDE. We fixed leaks in some framework classes as well such as:
  • Shell
  • RealSQLDatabase
  • TabPanel
  • VirtualVolumes
  • PopupMenus
  • MemoryBlocks

As you may know, the Real Studio IDE is created with Real Studio and the Realbasic language. We create it in the same way you create your projects. The chart below compares running the Real Studio IDE project in 2010r5.1 (blue) versus 2011r1(green). All tests were performed by running the project in the debugger and then closing the project. Incremental compilation was disabled.


You can see that after five runs of the project, Real Studio 2010r5.1 leaked over 45 megabytes of memory. Compare that to Real Studio 2011r1 (green) where after five runs, not a single extra byte of memory was leaked.

This is a huge improvement in the performance of the IDE. Before 2011r1, if you were using the IDE for long periods of time, you probably found that it would slow down to the point where you had to restart it. By doing this you were releasing the memory that had not been released by the IDE. This is no longer an issue in 2011r1 which means you can now run the IDE for very long periods of time without having to restart due to memory leaks.

While we believe we have found every leak in the IDE, it is possible there are others and there are certainly leaks that remain in some framework classes. Should you believe you have found a memory leak, create a simple sample project and include it with a new case in our Feedback system.

7 comments:

Bob Keeney said...

The chart appears to be missing.

Joe Ranieri said...

Sorry Bob, it should be up now.

Keith DeLong said...

This is great info Joe, thanks. I appreciate the work you're doing. I think I'm still seeing leaks in 11R1.

I recently switched from 08R5.1 to 11R1 and I've been experiencing the IDE slowing to a crawl and finally seizing on run after 3-4 hours continued use with a complex project. A restart of the IDE clears things up.

I'm leaving for vacation tomorrow. When I return, I'll do some memory testing as I work to see what I can discover. Do you have any tips for tracking what may be leaking?

Joe Ranieri said...

Keith, in an ideal world you'd be able to create a private Feedback ticket with the project (and everything required to build it) attached and we can deal with it from there. If not, you could enable MallocStackLogging and give us the output from the 'leaks' command line tool.

Photon said...

Joe, using 11R1 I am struggling with a memory block suddenly going from 26nnnn bytes of binary written with "mb.UInt8Value(pos)=mybyte" to all zeros, without an obvious correlation with my code execution. This seems new. I am working on this problem. Could there be an issue here with the memory leak fixes in 11R1?

Joe Ranieri said...

Photon, the only fix to MemoryBlock was that MemoryBlocks with a length of zero now get freed. There shouldn't be any other changes -- please file a bug with an example project.

Photon said...

Thanks Joe for your re-comment. The problem appears to be the location of the New MemoryBlock statement, which I had put in a Menu handler. There may have been a "race condition" involving my putting code in the menu handler. I am still learning. I move the statement to the subsequent method that writes to the MB.