I've actually noticed this too, but never bothered to
figure it out since it really wasn't a deal-breaker.
I'd be really interested to find out.
One thought spare memory being eaten up by the form,
but that doesn't really sound feasible.
--- Chet Gardiner <chetdude /AT/ pacbell DO.T net> wrote:
> Do you have "TALK ON"?
>
> 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.
> >
> >I've ensured that there is no order set on the
> DLY_INV file(explicit
> >"SET ORDER TO" to clear it), etc. I'm looking for
> ideas as to what to
> >look for-- I'm suspecting some kind of setting in
> code somewhere
> >that's causing data-manipulations in code to run
> slower than in the
> >command window... Any ideas? Thanks.
> >
> >
> >--
> >Derek
> >
> >
[excessive quoting removed by server]
©2006 Michael Madigan |
