Tuesday, July 08, 2008

Memory Lakes

Bob Hamburger started a new LabVIEW Insights blog with a great post about Insidious Memory Leaks. As he explains, it is important to avoid open/obtain/create operations inside a loop without corresponding close/release/destroy operations.

However, I am a little uncomfortable with calling the problem Bob describes a "memory leak." A memory leak is when a program allocates memory and then loses track of it, failing to ever deallocate it. LabVIEW, however, manages memory allocations for you*. If your VI opens a reference and never closes it, LabVIEW will automatically deallocate it when the VI stops executing. (I mentioned this automatic deallocation in my post about VI References).

The automatic deallocation doesn't help anything while VIs are running, which is why rampant extraneous allocations like opening references inside a loop will degrade performance over time and cause more serious problems when system resources run out.

But this isn't, technically, a memory leak. My colleague Stephen Mercer calls them "memory lakes" - allocating a huge pool of memory for no good reason.

Although perhaps a subtle distinction, I think it's important to maintain as much technical clarity as possible when describing problems like this, to avoid misunderstandings when reporting issues to NI Support (and, eventually, to us in LabVIEW R&D).

- Christina

* - If you call DLLs or other external components that do memory allocations outside LabVIEW's control, those could cause memory leaks that LabVIEW can't do anything about. Also, when I say LabVIEW doesn't leak things, I mean LabVIEW's not supposed to leak them when operating properly, so if it ever is leaking then it's a bug (and a high priority one).

1 Comments:

Blogger Yair said...

That's a great name.

Also, you bring up a good point about the need for accuracy. The next time I have this, I'll be sure to tell the AE that I have a memory lake. ;)

1:15 PM, July 09, 2008  

Post a Comment

<< Home