Benchmarking FoxPro Performance

1
Benchmarking FoxPro Performance
SESSION DEV04
Ted Roche, MCSDBlackstone Incorporated617.641.04
00www.bstone.com
2
Who is this guy?

• Director of Development, Blackstone, Inc.
• Author, Hackers Guide to Visual FoxPro 3
• Contributing Editor, FoxPro Advisor
• Microsoft Certified Solution Developer
• Microsoft Support MVP 94, 95, 96, 97

3
Introduction

• I dont get it. It ran fine on my machine.
• Gee, I tested it with 100 records and it was a
  lot faster than this

4
Agenda

• Performance Issues
• Data-based issues Rushmore
• Interface issues
• More is Better
• Benchmarking
• Brute Force Benchmarking
• Code Coverage Analysis

5
Data-based issues Rushmore

• Always, always, always (any questions?) create an
  index on DELETED()
• Index every field separately used in SQL SELECT
  or FOR clauses
• SET COLLATE
• DO NOT USE FOR OR NOT

6
Data-based issues Rushmore

• For queries, use SYS(3054) with ,1 and ,11 to
  determine performance of filter and join criteria
• Also, look at SYS(3050) for memory management

7
Interface issues

• Interface performance is perceived performance.
  Be snappy!
• LockScreen speeds native VFP updates
• For OCXs, move them off-screen to speed up
  refresh events

8
Overall tuning More is Better

• More processor
• More disk space
• More RAM
• More network bandwidth
• More disk I/O bandwidth

9
Brute Force Benchmarking

• FoxPro timer accuracy limited to milliseconds
• Use large loops to determine which code works
  faster
• Repeat tests, as caching, memory load, other
  factors often interfere.

10
Code Coverage Analysis

• SET COVERAGE TO filename ADDITIVE
• _COVERAGE system memory variable

11
Clear Events

• For performance tuning
• Cover the basics Rushmore, Screen I/O
• More is Better (and often cheaper)
• Benchmark suspected slow code
• Code Coverage Analysis to locate problems

12
Thank You!
Questions? Send e-mail here http//www.bstone.com
[phone]