| Re: speed of n_elements [message #17652 is a reply to message #17650] |
Wed, 03 November 1999 00:00   |
Pavel Romashkin
Messages: 166
Registered: April 1999
|
Senior Member |
|
|
> * I can't repeat your experience on Sun or Linux. On both those
> machines n_elements(data.flag) is much slower than n_elements(data),
> at least in a loop.
Thank you for the test, Craig. I repeated it and n_elements(data) was way
faster. But I was certain that I saw what i saw, so I reconstructed the
entire data system in the same way it was in my program. DATA in my program
is itself passed as a field of State structure inside a widget tree. Try the
following code:
**************
pro test, a
start=systime(1)
for i=0, 100 do temp = n_elements(a.data)
print, systime(1)-start
start=systime(1)
for i=0, 100 do temp = n_elements(a.data.flag)
print, systime(1)-start
end
************* ; Now, the outputs:
IDL> a=fltarr(1000)
IDL> b={a:a, b:a, c:a, d:a, flag:0L, name:'', other:0.0}
IDL> c=replicate(b, 500)
% Compiled module: TEST.
IDL> k={a:0L, data:c}
IDL> test,k
33.133333
0.033333302
> * I've always found that putting large data arrays into structures is
> a big loser. In my experience it's slow to create such structures
> and slow to extract the fields later.
I agree it is not nearly as neat as pointers. I don't find it noticeably
slow, at least with my array sizes. However, there are things that are really
advantageous in placing arrays directly as structure fields. For instance, I
can shift all arrays in the array of structures in one line:
data.(k) = shift(data.(k), n_pts)
while with pointers this does not work. In my opinion, the only drawback in
using pointers and (built-in) objects is that they take away from you some of
the tremendous advantages that IDL has in handling arrays.
Cheers,
Pavel
P.S. Not to mention the humiliating use of HEAP_GC after a crash of an app
full of pointers :-)
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
