Performance Considerations

While you can generally treat view descriptors like SAS data files in SAS programs, there are a few things that you should keep in mind:
  • It is sometimes better to extract CA-Datacom/DB data and place it in a SAS data file than to read it directly. Here are some circumstances when you should probably extract:
    • If you plan to use the same CA-Datacom/DB data in several procedures in the same session, you might improve performance by extracting the CA-Datacom/DB data. Placing this data in a SAS data file requires a certain amount of disk space to store the data and I/O to write the data. However, SAS data files are organized to provide optimal performance with PROC and DATA steps. Programs using SAS data files often use less CPU time than when they read CA-Datacom/DB data directly.
    • If you plan to read large amounts of data from a CA-Datacom/DB table and the data is being shared by several users (multi-user environment), your direct reading of the data could adversely affect all users' response times.
    • If you are the creator of a table, and you think that directly reading this data would present a security risk, you might want to extract the data and not distribute information about either the access descriptor or view descriptor.
  • If you intend to use the data in a particular sorted order several times, it is usually more efficient to run the SORT procedure on the view descriptor, using the OUT= option, than to request the same sort repeatedly (with a SORT clause) on the CA-Datacom/DB data. Note that you cannot run the SORT procedure on a view descriptor unless you use the SORT procedure's OUT= option.
  • Sorting data can be resource-intensive, whether it is done with the SORT procedure, with a BY statement, or with a SORT clause included in the view descriptor. When you use a SAS BY statement with a view descriptor, it is most efficient to use a BY column that is associated with an indexed CA-Datacom/DB field. Also, if you do not need a certain order, blank out the Default Key. Otherwise, you might cause an unnecessary sort.
  • If you use a Default Key, the interface view engine uses an index read instead of a sort if it can. Index reads are faster, but not always possible. For example, an index read is not possible if you specify multiple sort keys, multiple WHERE clause conditions, or a WHERE clause condition with a column that is not a key.
  • When you are writing a SAS program and referencing a view descriptor, it is more efficient to use a WHERE statement in the program than it is to use a sub-setting IF statement. The interface view engine passes the WHERE statement as CA-Datacom/DB selection criteria to the view descriptor, connecting it (with the AND operator) to any WHERE clause included in the view descriptor. Applying a WHERE clause to the CA-Datacom/DB data might reduce the number of records processed, which often improves performance.
  • You can provide your own URT with options that are fine-tuned for your applications.
  • See Creating and Using View Descriptors Efficiently for more details about creating efficient view descriptors.