× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I agree, D*B.

This interactive program from menu to first display, was taking /an average/ of five minutes when I started on it. The programmer that worked on it before me even did a popup window when they did an F3-Exit asking if they really wanted to exit, because every Exit cost them five minutes to get back in. It's now /way way/ down from that, but still horrendous performance.

I offloaded one algorithm to an external procedure that kept some internal variables static where they didn't change much.

I converted a whole lot of RPG I/O code (SETLL, READE, CHAIN, CHAIN CHAIN) to an SQL View that feeds all the twenty or so users jobs, where the joins and CASE WHERE happens only there. It was reading every single record in the primary file in every user's job and CHAINing a bunch of others, some of which it had to read through groups in other files looking for a value to match.

In the program I'm working on now, there's one condition that reads-equal through a group of records to check for a match to a list that is in a table from a generic file. I'm going to front-load those values to an array with ASCEND to do a %lookup instead. That made a HUGE difference in one place I worked at before.

--Alan


On 11/23/2022 9:01 AM, D*B wrote:
... if the query analyzer does its job, it choose the best way to get the result. best way could depend on index design, balance of the table, number of records, etc.

if you have "a /very /heavy performance burden", first step would be to analyze and to understand why the database engine is needing so much time (database monitor is your friend) before trying to optimize. mostly modifying statements doesn't help too much. ceating a missing index or changing your access logic or changes to database design could bring better results!

D*B

<Alan>
SQL references gives an example of EXISTS:

EXISTS (SELECT *
   FROM EMPLOYEE WHERE SALARY > 60000)

I would assume that the search in file EMPLOYEE stops when it finds the
first instance of a row that matches.

Is that so?

I'm asking because I'm modifying a program that has a /very/ /heavy/
performance burden, and I have to squeeze milliseconds out of it
anywhere I can get it.
</Alan>

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.