[Date Prev][Date Next][Date Index]
Re: ezcaIDL vs CaIDL
Yesterday Ben-Chin Cha wrote:
> I found out that in general that the caget in ezcaIDL is
> 3 times slower than CaIDL.
> In case 1 a caget is repeated 100 times on an AI record, in case 2 a
> caget is repeated 100 times on a waveform record with float type with 4000
> elements ...
> CaIDL ezcaIDL
>
> Case 1 1 sec 4 sec
> Case 2 3 sec 9 sec
This is simply incorrect. These results were the result of using the ezca
default timeout of .05 seconds. The correct comparison is with a very short
timeout in ezca. In this case the following results are obtained on a
Sparc LX.
CaIDL ezcaIDL
Case 1 0.72 sec 0.83 sec
Case 2 3.05 sec 3.16 sec
Thus, ezcaIDL is at worst 10% slower than CaIDL.
The benchmark programs which produced these results are:
For ezcaIDL:
casettimeout, 1.e-6
t1 = systime(1)
for i=1, 100 do s = caget('13BMA:test_ai', value)
t2 = systime(1)
print, 'Elapsed time for caget on AI: ', t2-t1
t1 = systime(1)
for i=1, 100 do s = caget('camac_wf1', value)
t2 = systime(1)
print, 'Elapsed time for caget on 4000 element waveform: ', t2-t1
end
For CaIDL:
t1 = systime(1)
for i=1, 100 do s = caget('13BMA:test_ai')
t2 = systime(1)
print, 'Elapsed time for caget on AI: ', t2-t1
t1 = systime(1)
for i=1, 100 do s = caget('camac_wf1')
t2 = systime(1)
print, 'Elapsed time for caget on 4000 element waveform: ', t2-t1
end
> I also found out that the startgroup and endgroup can not handle
> do loop get correctly in ezcaIDL (example is attached at the end.)
> If I use array with the 'do loop' it always return 0 (for double
> type PVs) or null string for the requested PV array. If I tried
> to redo array get for string type, ezcaIDL core dumped.
> PRO realarray_ezca,pvnames ; this will not work in ezcaIDL
> no = n_elements(pvnames)
> val = make_array(no,/double)
> castartgroup
> for i=0,no-1 do begin
> st = caget(pvnames(i),val(i))
> end
> print,caendgroup()
> for i=0,no-1 do begin
> print,pvnames(i),val(i)
> end
> END
This example reflects a basic misunderstanding of how IDL works. In IDL the
statement:
st = caget(pvnames(i),val(i))
passes the value of val(i), not a pointer to val(i). Thus, caget() cannot
return anything into val(i) using this syntax. It is completely analagous to
C - one would have to specify &val(i) to get a return value back in C. IDL
does not have an 'address-of' operator.
Ben-Chin is correct that in ezcaIDL one cannot read an array of values, each
from a different process variable, inside an asynchronous group. However,
one can read values into individual IDL variables, as she illustrated.
In CaIDL there are signficant restrictions on operations which can be done in
'asynchronous groups', i.e. between calls to ca_pend_event():
- caget() of a list of process variables can only return an array of doubles
or an array of strings. It is not possible to return other data types, and a
single call to caget() can only return all doubles or all strings.
- It is not possible to have an asynchronous caget() of a process variable
which is itself an array (e.g. waveform record)
Neither of these restrictions are present in ezcaIDL.
____________________________________________________________
Mark Rivers (312) 702-2279 (office)
CARS (312) 702-9951 (secretary)
Univ. of Chicago (312) 702-5454 (FAX)
5640 S. Ellis Ave. (708) 922-0499 (home)
Chicago, IL 60637 rivers@cars3.uchicago.edu (Internet)