Urs, I'm glad you keep the flag of the most important 'politically ' (_in-) 'correct platform' high ;-))
You wrote on Tue, 20 Jan 2004 22:45:04 +0100 > > 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? They are! Found comparabel results, allthough the PC where I tested this is not soo fast (took ~1.3s to generate the data you mentioned). I generated the same data and sent it to an empty sequence structure - it used 8.009 kB. I replaced the sequence with an indicator - took 16.009 kB. Insertted an transpose - it used 24.009 kB. I replaced the indicator with a sequence again - took again 8.009 kB. So I's assume transposing 2D-arrays is in-place. I was surprised, however, where the 3rd copy of the data occured or where it went to. No extra buffer allocation (black dot) was visibel anywhere. Maybe Greg or someone else from NI can shed some light? Greetings from Germany! -- Uwe Frenz ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr. Uwe Frenz Entwicklung getemed Medizin- und Informationtechnik AG Oderstr. 59 D-14513 Teltow Tel. +49 3328 39 42 0 Fax +49 3328 39 42 99 [EMAIL PROTECTED] WWW.Getemed.de
