Very Computer

- loading forms.  This is taking around 10 seconds for moderately complex
  forms, and has gotten to the point where I'm sacrificing another 2 secs
  to bring up a "Please wait" (which swallows all illegal input) just so
  the user has something concrete to abuse.

- record objects.  Moving from one record to another is *slow* - especially
  when code's been added to methods (arrive(), changevalue()) for the record
  or its fields.

Can anyone suggest strategies for speeding an application up?  Telling my
employer to equip all his staff with Pentiums?

BTW, yes, this will be on a network; I'm planning to install all forms on
the hard drive of each machine, so that the network is used for data only.

--
Bryce Utting      ()Z |                 Life is short.
University of Waikato |
Code grunt for hire   |                   Pray hard.

 > - loading forms.  This is taking around 10 seconds for moderately complex
 >   forms, and has gotten to the point where I'm sacrificing another 2 secs
 >   to bring up a "Please wait" (which swallows all illegal input) just so
 >   the user has something concrete to abuse.

Strategy 1: preload the forms at app load time and just show() each as
required. Library control is best. Won't be desireable in every case, but
for the slowest loading/most heavily used...

Strategy 2: If you have form 2 called often/only by form 1, consider
implementing form2's fields as a hidden (.visible=False) group of fields on
form 1 which "appears" over form 1 when required. Awkward to maintain
(overlaid fields are hard to select!) but quick to run, once the whole form
has loaded. Again, good for *some* cases.

Strategy 3. Have your employer upgrade to Pentiums. Hell, the amount Waikato
charges for email, it can afford it :-).

BTW, I'm getting acceptable performance out of a 486/25 w/8MB over a network
(forms too). Not great, but nothing to throw coffee at. Are you sure it's a
*4*86?  <g>

cheers,
peter

==============================================================================
             Peter Hyde, South Pacific Information Services Ltd
          Christchurch, New Zealand -- last time I looked outside
         <<< Please use c.d.paradox for ALL relevant messages! >>>

Downside: having to check each form for open() methods.  I'm only on this
one for another three weeks or so, so the users might just have to put up
with the poor performance...

Quote:> Strategy 2: If you have form 2 called often/only by form 1, consider
> implementing form2's fields as a hidden (.visible=False) group of fields on
> form 1 which "appears" over form 1 when required. Awkward to maintain
> (overlaid fields are hard to select!) but quick to run, once the whole form
> has loaded. Again, good for *some* cases.

You've put some fresh ideas in my head, though, about bringing up the "Please
wait" more quickly - thanks.  I really should have thought about keeping the
thing loaded permanently.  That one especially ;)

Quote:> Strategy 3. Have your employer upgrade to Pentiums. Hell, the amount Waikato
> charges for email, it can afford it :-).

Quote:> BTW, I'm getting acceptable performance out of a 486/25 w/8MB over a network
> (forms too). Not great, but nothing to throw coffee at. Are you sure it's a
> *4*86?  <g>

--
Bryce Utting      ()Z |                 Life is short.
University of Waikato |
Code grunt for hire   |                   Pray hard.

 > > Strategy 1: preload the forms at app load time and just show() each as
 > > required. Library control is best. Won't be desireable in every case, but
 > > for the slowest loading/most heavily used...
 >
 > I wonder how well this works with Windoze virtual memory, but I'll certainly
 > give it a try.  How many forms are you stacking up with this?

Depending on how you're configured & whether you have other apps running,
you may not be getting into VM use much. I frankly try to *avoid* using it
(setting it to 0 on some machines!).  In my apps, I typically have two or
three slow-loading/frequently-used forms preloaded, but I've heard of others
which go a great deal further.

 > Downside: having to check each form for open() methods.  I'm only on this
 > one for another three weeks or so, so the users might just have to put up
 > with the poor performance...

Doesn't take long, once you've written the manager method in the library.
 >
 > I've looked at paging where feasible, but still not found any worthwhile
 > tradeoffs.  Data model complexities have been making this sort of thing look
 > a little flaky anyway, but I wish I'd understood all this when I started.

Forget paging, is not what I meant. I've had it up to ^-- there with the
hassles of controllable user interface with paging.

Personally, I wish I knew lots of things before that I do now. But hey,
that's life.

cheers,
peter
==============================================================================
             Peter Hyde, South Pacific Information Services Ltd
     Christchurch, New Zealand -- what I can see through the water
        <<< Please use c.d.paradox for ALL relevant messages! >>>

Despite it's flakiness back then, and the fun on Beta and V1.0
we perservered and developed several business-critical apps
and rewrote some old Dbase ones as well.

All along, though, we have had performance problems. For the
record, all P4W user machines are DEC 486/66, 16MB RAM, most
have 2MB Video RAM, 256K cache. Screen resolution varies but
most are 1024x768. All use run-time.

So, what have we learned? For single user apps, especially
where the main function is to report or inquire upon volumes of
standing data, both development and runtime were very good.

However, as soon as we got into transaction processing systems,
and especially multi-user ones problems emerged. Transaction
systems usually required some fiddling with the various
arrive(), setfocus(), candepart() etc methods. As noted by Bryce,
when you get into these, especially on multi-record objects,
things slow down.

With the higher resolution systems, screen refresh times were
unacceptable to the users. Turning flicker-free off
in one instance gave dramatic
speed improvements, at the cost of some curious blinks one some
screen objects, but mercifully not the complete form.

All our applications originally had on their MAIN form, the
NBNZ logo (you know, the Black Horse) plus some bitmapped text.

Removing this object not only sped up the initial form load
as you might expect, but all the other forms ran noticably
faster. The bitmap was only 41K, so why this occurred
is a mystery. Anyhow, we took them all off and get by with
just a standard Text object.

A big hassle was the size of P4W's footprint. Standard setup
consumes about 25% system resources (measured by Winsock)
compared with Excel 4's 17-25%. Runtime dropped this to 21%.
However, with many user PC's already running over 60%, especially
those in the Dealing room (some of which sustain over 90%!),
the capacity was not there.
One application was a simple tableview showing the contents
of a network file, which changed as the file contents changed
as P4W should do and which we saw as a strength. Replacing just
the form with a clone in Powerbuilder, still accessing the
P4W database dropped the footprint from 21% to just 1%. This
meant that the users could actually run it!

Like other people in this group, we have had our share of
hassles with table corruption, locking wierdness, poor
report functionality etc. There were also plenty of messes
created by poor design and coding as we learnt. Not surprising
perhaps as this was our first foray into GUI apps
programming.

When new systems requirements arrived for WAN-based apps,
needing transaction control etc, we scouted for a Server
database to suit. We are currently trialling Oracle 7
on Solaris 2.3. The team felt this was a good
opportunity to investigate alternative development
platforms also, and we have chosen Powerbuilder.
Testing is focussing on WAN performance, plus ease of
development, especially in those areas where P4W
seemed difficult, such as form syncronisation, error
handling, object reuse (ie inherit, not clone) etc.

I should end by saying some positive things about P4W.
One particular app stands out as a testament to the
product. We support users in several NZ sites, and need
details of who is where and what H/W they have. Our
FLOORPLAN system initially shows a collection of buildings
and you click on the building/floor you want. This
displays a floorplan of desks with names etc. All
objects are created dynamically from database
of information about type and position.
Right click on a desk, and person and H/W details appear
and can be modified. Edit the details and the
screen object changes to suit. Desks and/or H/W
can be selected and dragged to a new position (or
cut and pasted to a new floor - never got multi-form
d&d working!).
Selection criteria can be entered (such as show
all desks with 386's. or who's on Ethernet), and
all relevant objects change colour. Reports
can be run on objects on the floor, or just those
highlighted and so on. Anyway, we're proud of it, the
admin user thinks it's neat and best of all it was
both quick (about 5 days) and *FUN* to build. So regardless
of the outcome of the current trial, we will keep
and continue to use P4W for at least some apps.

Cheers,

Mine, not theirs. Of course.

: All along, though, we have had performance problems. For the
: record, all P4W user machines are DEC 486/66, 16MB RAM, most
: have 2MB Video RAM, 256K cache. Screen resolution varies but
: most are 1024x768. All use run-time.

As PC magazine's tests have shown all along, use 640x480 at about 256 for
maximum WinVideo performance...  But I personally use 1024x768...  :-P

: So, what have we learned? For single user apps, especially
: where the main function is to report or inquire upon volumes of
: standing data, both development and runtime were very good.

Agreed.  

: However, as soon as we got into transaction processing systems,
: and especially multi-user ones problems emerged. Transaction
: systems usually required some fiddling with the various
: arrive(), setfocus(), candepart() etc methods. As noted by Bryce,
: when you get into these, especially on multi-record objects,
: things slow down.

I've found that if I do some queries and those only retrieve a handful of
entries (less than a dozen or so), it's actually a lot faster to open a
tcursor and use locates to dump them to a temporary table.  Of course, I
don't get all those nice relationships...

: With the higher resolution systems, screen refresh times were
: unacceptable to the users. Turning flicker-free off
: in one instance gave dramatic
: speed improvements, at the cost of some curious blinks one some
: screen objects, but mercifully not the complete form.

: All our applications originally had on their MAIN form, the
: NBNZ logo (you know, the Black Horse) plus some bitmapped text.
: Removing this object not only sped up the initial form load
: as you might expect, but all the other forms ran noticably
: faster. The bitmap was only 41K, so why this occurred
: is a mystery. Anyhow, we took them all off and get by with
: just a standard Text object.

Was that logo "zoomed" or stretched in any way?  That will slow down
PDOXWIN quite a bit...  Use the correct size to startwith, and leave it
on 100%.

: A big hassle was the size of P4W's footprint. Standard setup
: consumes about 25% system resources (measured by Winsock)
: compared with Excel 4's 17-25%. Runtime dropped this to 21%.
: However, with many user PC's already running over 60%, especially
: those in the Dealing room (some of which sustain over 90%!),
: the capacity was not there.

Agreed...  I use the Paradox Desktop that comes with the book "What Every
Programmer should know about PDOXWIN" by Mike Prestwood, which launches
multiple sessions of PDOXWIN (one for itself).  After two or three
sessions plus my other programs, AFTER DARK won't do any of the complex
stuff any more!  :-/

: One application was a simple tableview showing the contents
: of a network file, which changed as the file contents changed
: as P4W should do and which we saw as a strength. Replacing just
: the form with a clone in Powerbuilder, still accessing the
: P4W database dropped the footprint from 21% to just 1%. This
: meant that the users could actually run it!

That's a good idea...  I wonder how much GDI resource would a program
written in C/C++/WinPascal/VB and ODBC drivers would take?

[some things deleted]

: I should end by saying some positive things about P4W.
: One particular app stands out as a testament to the
: product. We support users in several NZ sites, and need
: details of who is where and what H/W they have. Our
: FLOORPLAN system initially shows a collection of buildings
: and you click on the building/floor you want. This
: displays a floorplan of desks with names etc. All
: objects are created dynamically from database
: of information about type and position.
: Right click on a desk, and person and H/W details appear
: and can be modified. Edit the details and the
: screen object changes to suit. Desks and/or H/W
: can be selected and dragged to a new position (or
: cut and pasted to a new floor - never got multi-form
: d&d working!).

: Selection criteria can be entered (such as show
: all desks with 386's. or who's on Ethernet), and
: all relevant objects change colour. Reports
: can be run on objects on the floor, or just those
: highlighted and so on. Anyway, we're proud of it, the
: admin user thinks it's neat and best of all it was
: both quick (about 5 days) and *FUN* to build. So regardless
: of the outcome of the current trial, we will keep
: and continue to use P4W for at least some apps.

Wow...  That's a good one...  Too bad Borland don't do a applications
contest like Corel with their art contests!  :-)

--
==============================================================================

||   (the rest of this .sig is under construction...)                       ||
==============================================================================

They do in Aussie -- last year some kind of medical app (PdoxDos) won --
though I gather it had a heck of a lot of supporting C code, as it turns
out.

cheers,
peter
==============================================================================
             Peter Hyde, South Pacific Information Services Ltd
          Christchurch, New Zealand -- last time I looked outside
         <<< Please use c.d.paradox for ALL relevant messages! >>>