On Mar 31, 2006, at 5:08 PM, Derek Kalweit wrote:
> Hello. I've noticed a lot in the past that things simply run
> slower-- SQL, scans, etc., while running our app code(both in VFP and
> via runtimes). I have an example that I came across today-- it's a
> very simple SQL statement(don't ask why; I didn't write the code; I
> would have written the entire section of code differently):
>
> SELECT * FROM DLY_INV WHERE DATE = DAILY.START_DATE INTO CURSOR
> crsFoodUsed
>
> With coverage profiling on, this takes about 320ms in the app(207k
> records in table)-- with it off, it's 300-310ms(so it's not coverage
> profiling overhead, not that it really could be, considering it's one
> LOC).
>
> This same code, even executed in a loop(as this is done in code), is
> 9-11ms via the command window. All situations I've seen aren't this
> drastic, but this specific one is over 30 times slower in the app code
> versus the command line.
Assuming no difference in CPU load, most of these differences are
attributable to Fox's memory usage. It is notorious for using as much
memory it can get, but is not too smart about the difference between
actual RAM and VM. When you're at the command window, most likely
there are relatively few things using RAM, so the query proceeds
efficiently, but when you're running the app, there are lots of other
tables/ indexes/ programs in memory, so you may get into VM paging
effects.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
©2006 Ed Leafe |
