Experimental Physics and
Industrial Control System

[email protected] · Tue, 05 Apr 94 15:09:27 -0500

As promised at the LANL Epics 'family' meeting in March... here are
some test figures/times of what it takes to load the verbose ascii .db
files verses the binary .database files generated by dct and gdct.

First lets look at the input files themselves:

This is the binary DCT database file:
-rw-rw-r--  1 jbk       1843338 Apr  5 10:00 bpm.database

This is the DCT short form report:
-rw-rw-r--  1 jbk       1167186 Apr  5 10:05 bpm.ascii

This is the ascii database from gdct:
-rw-rw-r--  1 jbk        451111 Apr  5 10:29 bpm.db

As you can see, the ascii database file is about 25% the size of the
binary database file (note, however that the ascii database file does
not include the 200,000 byte default.dctSdr information...)

Ok, so here are the loading time figures:
==============================================================
tickGet
value = 1012 = 0x3f4
dbLoad "/home/phebos2/WINANS/tmp/evansbig/bpm.database"
value = 0 = 0x0
tickGet
value = 2112 = 0x840
==============================================================
tickGet
value = 1081 = 0x439
dbLoad "../../default.dctsdr"
value = 0 = 0x0
tickGet
value = 1413 = 0x585
dbLoadRecords "/home/phebos2/WINANS/tmp/evansbig/bpm.db"
Warning: No EPICS version information in db file
value = 0 = 0x0
tickGet
value = 2465 = 0x9a1
==============================================================
2112-1012 = 1100   (clock time for the binary load)
2465-1081 = 1384   (clock time for equal information from ascii load)
1384/1100 = 1.2581818181  (25.8 increase in time for ascii version)

For the record content information only:
2465-1413 = 1052   (clock time for ascii load w/o default.dctsdr)
1100/1052 = 1.0456273764 (4.5% DECREASE in time for ascii version)

The percent increase in time when using the dbLoadRecords on the ascii
database file is 25.8%.  These loads were done on an unmonitored
ethernet within 15 minuites of eachother... I am assuming that the
acitvity was consistant enough in that period to factor out of
consideration.

Please note that this IOC was operating with FTP (as opposed to NFS)
when accessing the files, therefore there is about a 2-second overhead
of each file-read.  Thus the NFS difference in load times would be
noticably less.  And if it is safe to assume that vxWorks does nothing
significantly different in terms of task scheduling under NFS, redoing
the above test should skew things in favour of the ascii file loader.

----

Notice that the dbLoadRecords command (curently) requires a dbLoad to
preceed it.  And that the time for it was included in the worst case
calculations (it seemed fair to me.)

OK, so for one single database that contains 2722 records (that are
about 50% ai and 50% ao) we are taking about 25% longer to load them
when using the ascii file transfer.  But when loading a database in
components, you will load the default.dctsdr file once and then, just
load the ascii files.  And since it is actually 4.5% faster to
load the ascii part than compared to the binary equivelant... those
implimentations that load their databases in components actually
run FASTER if they have more than 6 parts to them... as is not uncommon
for the APS.

A non-quantitive observation of the situation would show the lack of a
need to maintain the code that operates on the binary and old 'short
form' report files.  As well as the elimination of the headache of
having to keep them in sync (which has been a significant complaint
from APS users.) In fact, those users that have found out about the
availability of the dbLoadRecords command no longer use their binary
databases.  They claim that converting their home-brewed database
configuration file formats (ranging from C programs that generate
short-form reports to PC based database tools and text editors) into
the required binary databases, can take as much as 20 minuites when
using DCT in batch mode... and as much as 4 minuites when converting
them to the ascii .db format with the tools we wrote to assist in the
migration from binary to ascii databases.

I will provide the database ascii and/or binary files to anyone that is
interested in rerunning this test for themselves.  (preferably someone
that is using NFS?)

--John

! John Winans                     Advanced Photon Source  (Controls)    !
! [email protected]       Argonne National Laboratory, Illinois !
!                                                                       !
!"The large print giveth, and the small print taketh away." - Tom Waits !

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System