Dear wireworkers and data transposers, I made a short test on my LV7/MacOS-10.3.2 by creating a 1 million element DBL 2D-array of 1000x1000 size by creating random numbers in two nested For loops. Transposing the array before displaying the values in a plain regular 2D-array indicator adds 8MB and 1 block to the 16MB in 7 blocks of memory consumption. Execution time raises from 758ms to 972.7ms when doing the transpose function before displaying the values.
However and this is the point, only a marginal overhead is present if no FP-display occurs, whereas the created 2D-Array is just disassembled by autoindexing in two nested For loops again. In this case the VI consumes 8MB of memory in 3 blocks in booth cases with the transpose function only adding a marginal overhead of 0.3kB. Execution time here raises from 672 to 686ms. So the test shows that it is fair to state that ''Transpose Array'' is an inplace function at least under MacOS-X. Don't let yourself fool by FP buffering which puts a much larger strain on LabVIEW's memory manager compared to plain BD-calculations. In fact due to the results, when FP-display takes place it easily consumes multiples of what the BD consumes. Are the results duplicatable on the politically correct platform too? Anyway happy wireworks as usual... Urs Urs Lauterburg Physics demonstrator LabVIEW wireworker University of Bern Switzerland The conclusion >Well I was too lazy to do the test you performed, and I didn't find >anything on NI's web site. But I'm nearly certain that the LV >developers have said that transpose is an inplace function at several of >the NIWeek session's I've attended. Maybe that's no longer true or >maybe my memory has turned to mush (fairly probable given my advancing >years). > >It's certainly possible to transpose an array while reusing the same >buffer, you just have to make sure to move the elements in the right >order, and you need a tiny scratch buffer. But I believe your test >results. > >Maybe someone with inside knowledge will chime in here... > >Jason Dunham >SF Industrial Software, Inc. > > >-----Original Message----- >From: Simon Whitaker [mailto:[EMAIL PROTECTED] >Sent: Tuesday, January 20, 2004 2:03 AM >To: Info-LabVIEW List >Subject: Re: Array Wish list > >On Mon, 19 Jan 2004 22:42:22 -0800 Jason Dunham wrote: > >> As far as I've ever heard, the transpose arrays don't use any extra >> memory. The transpose function is done "in place". I'm sure a few >extra >> bytes are needed for temporary storage, but supposedly the same array >> buffer is reused. I would guess that the graph transpose option is >also >> not a memory hog. > >Although a transposed array will consume the same amount of memory as >the original array, the transpose function involves creating a new >array, >populating it using data from the original array, then deleting the >original. This can have a significant effect on memory usage with a >large array. > >LabVIEW stores multi-dimensional arrays as a list of data items plus >4 bytes per dimension to store the size of that dimension. You can >therefore work out how much memory an array will use: > > size of array item in bytes x no. items + 4 x no. dimensions > >The "no. dimensions" element becomes insignificant for large arrays. >So, an array of a million 16-bit integers will consume around an extra 2 >million bytes (about 1.9MB) during transposition. > >You can confirm this by profiling some sample VIs, one with >transposition and one without. I created two VIs: the first creates a 2D >array containing 10,000,000 32-bit integers (10 x 1,000,000) and writes >it to an indicator. The second is a copy of the first, with a transpose >array node just before the indicator. The first VI consumes almost >exactly 40,000K less than the second (84,000.94K vs 124,000.98K). >According to the above formula the array will consume c. 10,000,000 x 4, >= c. 39,000K. > >You may not need to worry about this memory hit if you're transposing >small arrays, but if you're transposing arrays with many millions of >elements your memory usage will increase significantly during >transposition - especially if you're using a large data type like an >extended precision float. > >All the best, > >Simon > >Simon Whitaker <[EMAIL PROTECTED]> >Software developer, Tiab Ltd >tel: +44 (0)1295 714046 >fax: +44 (0)1295 712334 >web: http://www.tiab.co.uk/
