Urs, you're dead right. I get the same results here (on Windows/LV7.0). My apologies to anyone I misled yesterday with my assertion that Transpose 2D is a memory hog. Clearly, it isn't.
Jason, you're right too - of course it's possible to transpose an array without making a complete copy. I'll turn my brain to ON before cooking up these wild hypotheses in the future. I'm still interested to learn why the Transpose 2D Array wired to a FP indicator in my initial experiment (and Urs' first example below) consumes so much extra memory? Intuitively it would seem to require no more memory than the same VI without a transpose array function. All the best, Simon On Tue, 20 Jan 2004 22:45:04 +0100 Urs Lauterburg wrote: > 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/ > > > > Simon Whitaker <[EMAIL PROTECTED]> Software developer, Tiab Ltd tel: +44 (0)1295 714046 fax: +44 (0)1295 712334 web: http://www.tiab.co.uk/
