Quote:
Originally Posted by Kevin Sevcik
... Did it increase the allocated memory by 1 element? 10? Some constant somewhere? Did it double the size? I can get at this info for a rather lot of other programming languages, but I haven't a clue what labview is doing for me behind the scenes.
... Of course this is, again, just so much voodoo. I have also coded up a rather gate-hungry FPGA program.....
|
The forums for LV often cover these sorts of implementation details, but they of course change over time. Both the system memory manager and the internal array allocator round up to some degree before allocation. The insert into array doesn't do anything beyond this, but the loop boundaries use a bounded doubling scheme. And all memory management does indeed slow loops down, just as in any language. It is also quite easy to preallocate the array and replace elements if you want to remove the memory management and increase the speed.
In other words, LV will not prevent you from writing code that operates inefficiently. The compiler will do what it can to improve things, and as in any language recognizing and measuring what code is doing takes consistency and practice. One benefit to rapid development languages like LV is that while the array insertion code your fellow student wrote wasn't optimal, it sounds like it did work. If a non-CS user is able to get valid results from their computer, that is a huge improvement over what they could often achieve with a language that gives them super low level control. Hopefully when the time comes for optimizing, they are then able to keep the correct results as they experimentally modify their implementation.
If you have further questions about how LV implements its voodoo, both the NI LV forum, and now this forum are a great place for it to take place.
Greg McKaskle