Speed Issue 4

[whateveragain]

I have two VFP applications similar in functions but different formulas. One is 2 MB larger than the other. The larger one works fine on my client's computer, but the smaller one does not work well. It's very slow. Both applications work well and fast on two of my computers. What would make apps work well on one computer and not others? My associate had the same problem and the speed issue wasn't resolved until he purchased a new hard drive. Even so, he's sure it's my application because the larger app worked fine on his computer. I believe it's a computer maintenance issue, but neither of them agree with me.

 

[Olaf Doschke]

Hard to tell. Outside of a VFP application, what perhaps does affect performance mostly is RAM and the speed of the TEMP folder, as VFP does save it's cursors/temp data there. This should by all means be configured locally and the faster that hard drive the better.

Otherwise you give way too few informations to see why something is fast on one and slow on another computer.

Could be data. If data is not indexed, performance can slow down very fast and if the database is almost empty on one computer and has wuite some entries on the other one that could be the important difference.

You can do logging of performce via SET COVERAGE - which, though mainly a tool for debugging and development, also does run within the EXE runtime. You can then see what commands do take long and optimize code.

Bye, Olaf.

 

[Mike Lewis]

So, you're saying that the larger app works OK on your computer, your associate's, and your client's? In that case, forget about the larger app. It's a red herring. Focus on the smaller app.

So you've got an app that runs at an acceptable speed on some computers but not others. The first thing is to determine if it is in fact the identical app, that is, if it's the same EXE, the same CONFIG.FPW (if any), and so.

After that, ask yourself what's different in the different systems. Does the fast one have more RAM, a faster hard drive, or what?

Other things to look for:

- Different anti-virus programs.

- Where the app is installed (if it's installed on a local hard drive, it's likely to run faster than from a network).

- Where the data is installed (again, local hard drive vs network).

Once you've determined what's different, you stand a good chance of finding out why one is slower than the other.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[dbMark]

The size of an VFP .exe file means little or nothing beyond the fact that a larger file size will take a little longer to load the application into memory. If it's from a local drive, there is probably very little time delay, but if over a network, it all depends on the speed - fast or slow - of that network and network connection. For example, loading using 100 mbps may be noticeably slower than 1000 mbps.

 

[whateveragain]

Thanks all for the input. I did neglect some info - sorry. The client with the slow app is networked; however, they did a stand alone pc installation (we have 2 types of installations available with this application). I have a button that re-indexes all tables on their machine. She did forget to select that option, but now that she has, she claims it's still slow. I'm afraid they are not very cooperative with giving me details about their hard drive, computer maintenance, ram, but heavily imply it's lack of speed is our responsibility so I'm running out of ideas.

 

[TamarGranor]

Does your reindex button use REINDEX or does it actually delete the indexes and re-created? If it's just REINDEX, it could be carrying some junk along.

Would they be willing to send you their data, so you can try the app against it? That would be a good way to see whether it's something about these tables causing the slowdown.

Tamar

 

[Steve Bowman]

maybe i am wrong but i do want to go back to the larger application. since both "are very simular" in function why is one much larger? it would take lots of code to make that difference. I am wondering if you might have a datatable "included" into the build. depending on that answer and if that table has an important role then a memeory cached table loaded with the exe could cause one to run faster particularly in a networked environment. I have never distributed an app with an included table but i think it can be done and have accidently done it once.

Just a thought while reading the post

Steve Bowman
Independent Technology, Inc.
CA, USA

 

[TamarGranor]

If a table were built into the EXE, it would be read-only in the application, so that's unlikely.

More likely is that some of the class libraries in the larger EXE contain a lot of deleted records and that packing those classlibs would shrink the EXE.

Tamar

 

[Steve Bowman]

I had more in mind of like a ZipCode lookup table or something static. Like i said just a thought while i was reading the thread

Steve Bowman
Independent Technology, Inc.
CA, USA

 

[craigber]

Zip codes aren't static. There aren't lots of new ones added, but it does happen.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com/blog

 

[dbMark]

Tamar wrote:

Does your reindex button use REINDEX or does it actually delete the indexes and re-created? If it's just REINDEX, it could be carrying some junk along.

I had an issue once where some 20MB tables had bloated indexes that overtime approached 1GB in size. The code was not deleting the existing CDX but just concatenating the rebuilt index onto the end of the index file, sort of the way a memo file can bloat over time.

* WARNING: CDX file will bloat if reindexed this way
*          Deleting the tag first does not make a difference
SET SAFETY OFF
USE myTable
DELETE TAG myIndex
INDEX ON FIELD(1)+FIELD(2)+FIELD(3) TAG myIndex
SET SAFETY ON

I have not noticed any problem with index bloating when deleting the CDX before calling INDEX (remember to SET SAFETY OFF first to avoid a warning message window) or using REINDEX.

 

[Mike Lewis]

DbMark,

Thanks for that. I think I've come across that advice before, but had forgotten it. It's worth remembering.

By the way, you mentioned SET SAFETY. SAFETY should be OFF in all applications. You don't want users seeing scary messages about deleting files. It should only be ON when working in the development environment.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Auguy]

DbMark or Mike, A quick question. I've always used.

DELETE TAG ALL

Does that make any difference in reference to your warning? If you were talking about physically deleting the CDX file, how would you go about that on an open table?

Auguy
Northwest Ohio

 

[Mike Lewis]

Auguy,

Good question. You can't delete the CDX for an open table, even if another user has opened it. The whole operation would be done in maintenance mode, that is, when everyone is logged out.

That's something to keep im mind if you want to write generic code to re-create the indexes. Normally, if I wanted to re-create every index in a database, I'd use ATAGINFO() to get all the expressions into an array, then loop through the array, issuing an INDEX command on each one.

But you can't do ATAGINFO() for a closed table. So you'd have to get the tag info - for every table in the database - before you close everything. Not a problem, but something to be aware of.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Auguy]

Thanks Mike, I don't think I've ever seen CDX bloat, but maybe I have and don't know it (LOL). All of my apps have a CdxTable that houses the index info for all of the tables in the app and I use those when "Re-Indexing" with "Delete Tag All". I will keep CDX Bloat in mind when future problems show up.

Auguy
Northwest Ohio

 

[TamarGranor]

DELETE TAG ALL has the same effect as deleting the CDX.

Tamar

 

[Mike Lewis]

I recently came across a similar issue with DROP TABLE.

An application did a daily download of data from SQL Server. Each day, the app would delete the existing tables, and re-create them, fetching the fresh data from the back-end.

This was taking about 20 minutes per day, and the client asked me to see if it could be speeded up.

I did a profile on it, and, to my surprise, found that a lot of the time was being spent on the DROP TABLE statements. I changed the multiple DROP TABLEs to a single DELETE FILE *.*. I then recreated the DBC and proceeded as before.

To my amazement, the time went down from 20 minutes to five minutes. I really can't explain why. If I hadn't seen it with my own eyes, ......

I suppose the moral of the story is: Before you can speed something up, you have to figure out why it's slow.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Mike Lewis]

Mike (Yearwood),

Good to hear from you again. Where have you been? (I've been here all along.)

I'm sure you're right about the checks and locking. Even so, I'm surprised it took as long as it did. When I tried a DROP TABLE from the command window (in the same database), it was instantaneous.

Oh, well. That's FoxPro for you.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Olaf Doschke]

Tamar,

In regard to DELETE TAG ALL:
for DBFs belonging to a DBC DELETE TAG ALL does more than deleting the CDX file, there are also index related records in the DBC this wipes out and thus just deleteing the CDX file is not a good idea, it results in an error message when using the table, eg to index it.

If you want to reindex a whole database it will be much easier using SDT, but neglecting tools I'd then rather have meta data about indexes (like SDT does have), do DELETE TAG ALL on all DBFs, recreae index tags from the meta data information and then PACK the DBC.

In regard to local single user installation vs LAN installation it's merely LAN spped limiting performance, bad indexes in the form of bloated indexes do slow down, but non ideal index expression can slow down the application too.

Ideal indexing is not a simple thing, you got to know the queries to create optimum indexes. It's not a good idea to simply index all fields of a table for example. And a fully optimizable SQL query reported by SYS(3054) might not mean the best performance in any case. Unfortunately performance tuning is not that simple.

Bye, Olaf.