My NIWeek 2008 Plans

I'm really looking forward to NIWeek this year! I recently bought an iPhone and plan to make the most of it at the conference. I will be blogging from the convention center and I'll be on Twitter as well.

On Tuesday evening I'll be hanging out at The Iron Works BBQ with some folks from LAVA, OpenG and NI. If you'd like to join us, there's still space available. Just add yourself to the evite and pay the organizer (Christopher Relf) $39 via Paypal, then come to The Iron Works, a short walk from the convention center, and enjoy all-you-can-eat BBQ. There are even door prizes!

I'm not presenting any sessions this year, but I will be one of the volunteers at the "Ask the Experts" booth in the Expo hall on Tuesday from 5:00 PM to 6:00 PM. Feel free to stop by, say "hi" and tell me what you love/hate about LabVIEW.

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).