Author: Bill Woodger
Subject: Reply to: CPU time Vs Number of records
Posted: Tue May 10, 2016 3:58 am (GMT 5.5)
Have you for certain determined that the keyed-access is a performance problem? If no, then you need to do so before proceeding.
If yes, lots of questions about the number of reads, the order of the reads and stuff like that. Index levels, number of index buffers, size of CI, data buffers, all of those can affect performance. If you are doing a lot of reads, you can expect significant savings by doing things differently. With 20,000 records, you can consider storing the keys and data you need in a COBOL table, in key sequence, and using SEARCH ALL or a hand-coded "binary chop".
Lots of things you can do, but exactly what depends on the data, and exactly what you are doing with it.
If it is one of those situations where "I can't change the program", reducing the size of the file and looking to see if you can use BLSR as Robert suggested can help performance, but not necessarily with significant saving of CPU usage.
Subject: Reply to: CPU time Vs Number of records
Posted: Tue May 10, 2016 3:58 am (GMT 5.5)
Have you for certain determined that the keyed-access is a performance problem? If no, then you need to do so before proceeding.
If yes, lots of questions about the number of reads, the order of the reads and stuff like that. Index levels, number of index buffers, size of CI, data buffers, all of those can affect performance. If you are doing a lot of reads, you can expect significant savings by doing things differently. With 20,000 records, you can consider storing the keys and data you need in a COBOL table, in key sequence, and using SEARCH ALL or a hand-coded "binary chop".
Lots of things you can do, but exactly what depends on the data, and exactly what you are doing with it.
If it is one of those situations where "I can't change the program", reducing the size of the file and looking to see if you can use BLSR as Robert suggested can help performance, but not necessarily with significant saving of CPU usage.