Re: Power Objects: Ye gods it's slow!

In a previous article, jlove_at_engin.umich.edu (Jacob Love) says:

>In article <4hj9js$6g5_at_madeline.INS.CWRU.Edu>,
>Jeffrey J. McWilliams <cd827_at_cleveland.Freenet.Edu> wrote:
>>I've got a query screen that queries 26,000 records based on matches in
>>1 to 4 fields - and it only takes about 5 seconds for the query to run
>>and display the resulting matches in a scrollable list box.
>>I'm running a 486DX4-100 with 16MB RAM.
>>
>>Personal Oracle 7.1.
>
>I posted a bit on this thread a while back, but I've been doing some
>more, so here is an update. My test machine is a 486 66MHz with 20M of
>RAM, the workstations that will run the product are all 90MHz Pentiums
>or better connecting to Sun Solaris Oracle databases. When I posted
>originally, I didn't see the performance problems noted by the
>contributors. Since then, I have brought up some OPO projects based on
>Blaze, and I most definitely do see the sluggishness. Some of these
>Blaze projects involve very simple forms running against databases with
>very few records. Moving from running the form to running an
>application compounds the problems--the performance seems to quickly
>degenerate to unacceptable. I suspect that this is what is behind
>Oracle's decision to abandon Blaze in favor of Oracle Lite (as reported
>in an announcement originating at the S.F. Oracle Developer's
>Conference). However, moving from Blaze to Oracle for Windows95 on
>the 486 makes a huge difference. I find the performance to be
>quite acceptable--at least for these small applications. I do not
>yet have enough experience in the production environment, but I would
>expect the results to be even better, since Oracle itself will not
>be exhausting resources on the client machines. I will post if I
>discover otherwise.
>
>All in all I think OPO is a pretty good v1 product, and I am very
>much looking forward to v2.
>
>--
>-----------------------
>Jack F. Love
>Opinions expressed are mine alone, unless you happen to agree
>

Some additional input by myself.
One of our forms is a bit like the contacts sample application. Along the top of our form the user may enter search criteria which will be used to query the database. In the middle of the screen is a listbox in which appears all matches to the query - but just some of the fields. Along the bottom of the screen are the remaining fields for the record. Clicking on a record in the listbox makes the remaining fields at the bottom of the screen become populated with that record's data.

Some problems - the code that updates the field on the bottom of the screen based on which record is highlighted in the listbox was borrowed from one of the sample apps. It's actually quite horribly slow - most of it is in the PostUpdate() method of the listbox. Even with only 40 matches, the further down on the list you go, the longer it takes the program to update the field fields along the bottom of the screen.
I improved that by rewriting some of that code. Changing MaxMemSize() on the form property box didn'thelp even though this is supposed to cache records in memory. The most disturbing problem, however, is that if the query returns more than about 600 records, power objects causes a general protection fault and dies. It doesn't matter if I'm running the application from within the designer, compiled with the runtime , or compiled into a separate EXE file. I've had to program in checks so that if the user's query returns >600 recs, a dialog box informs the user to narrow his search, and try again. With 16 megs of RAM THIS SHOULD NOT be happening.
My records are less than 1K total in length. 600 records is only 600K of memory.

Does anyone have any ideas on this?

Jeff

-- 
Jeff McWilliams      cd827_at_cleveland.freenet.edu
The minstrel boy to war has gone,
In the fields of death you'll find him.