Hmmm, well Dan, I haven't tried the blue face paint, but I have tried
holding my breath and I did almost turn blue.
I agree that 23,000 items in a lookup list is excessive and I agree it's
not good practice. But, up until this Windows 7 thing, it has worked
beautifully! Very fast and very useful.
The big benefit to the current design is that the SKUs that they are
entering can be up to 18 characters long, have NO rhyme or reason, and
change every couple of weeks...new ones added, old ones gathering dust
(they don't want to remove the old ones just in case they want to look
something up.) They have been adding 200 to 300 new SKUs every other
week on average. Here's a list of some of them:
DCSRGSC305SSLP
DCSRGS486GLSSLP
HL67A750A1FXZA
UR48DTCLRGLSRFD
UR48HT4CLRGLSDR
VGRC4854GQDCOLO
XXUN55B6000VFXZA
Now, all of the characters in the alpha/numeric string means something,
but it's not consistent (what it means.) The "48" might be the width,
or it might have no bearing on any specification of the appliance (my
app is primarily used by white-good retail stores.)
Where the problems really come in is that the companies that use my
software have a high turnover in sales people, and the newbies are
clueless on SKU #s and what they might mean. And, unfortunately, if they
get one letter or digit wrong, it can produce a costly problem due to
the wrong item being ordered and/or delivered...sometimes the mistake is
caught, sometimes not.
The biggest problem, though, is that the sales manager (new co-owner)
has the mentality of "I don't care what you do, just do it as fast as
you can! We have more tickets to write!" so there are a lot of mistakes
and errors with little to no emphasis on catching mistakes. I've tried
to get them to switch over to barcode labels and scanners for SKU input,
but they can't keep their price tags straight, much less bar code labels.
Anyway, enough with the defense of how it's done.
OCX files are typically written in Visual C+...at least that's my
understanding. They are, essentially, much like DLLs, or FLLs. Beyond
that is beyond my understanding. To use them, you copy the OCX file onto
the hard drive, register it with "regsvr32 nameof.ocx" and it becomes
available for use in your application.
As you said, the most confusing part of this is that there is such
performance difference between the run-time execution and running the
PRG files from the IDE, with everything else the same. And, likewise,
the difference in performance between the run-time execution with the
EXE file being on a networked drive vs. the same code being loaded
locally. THAT really makes no sense. That's what stumped me. Quite
obviously there is a significant difference in how VFP allocates and
manages memory when the pseudo code is loaded from a network share vs. a
local folder.
Oh, and to your last comment, I am loading the list from an array now. I
tried using a cursor and switched to the array approach during the
testing (after the problem showed up.) Using an array is about 40%
faster...unless it's run from an EXE on the local Win7 drive! Then it's
about 2 seconds faster (76 instead of 78 seconds).
But, again, thank you for the analysis!
Mike
> On 3/3/2011 3:25 PM, Mike Copeland wrote:
>> Okay, now we're grasping...but I'll try it!
>>
> Have you tried painting your face blue and running the app while
> standing in a pail of molasses? You've tried damned near everything else!
>
> The most interesting thing about this problem is that the performance is
> bad when running the .exe, but good if you run the .prgs (i.e., really
> the .frxs). My intuition is still that it has something to do with that
> 23,000 iteration loop. The huge loop makes it highly probable that it
> has to do with the way memory is managed, and that means that the .exe
> manages memory differently from the .frx. But wait! You've got an .ocx
> doing all the work in the loop. So what about the .ocx could act
> different in an exe?
>
> I never use .ocxs, but I'm under the impression that they are already
> compiled, and thus aren't included in 'build'ing your project. If this
> is so, then Tracy's point about the run-times becomes interesting. IOW,
> are you compiling your .exe with the same version (SP1 vs SP2) that the
> OCX was compiled with, and do the run-times match the version you and/or
> the OCX are compiled with? Note that there were at least two versions
> of SP2, plus two hot fixes to be applied afterward.
>
> I've seen something like this (but not nearly as dramatic) in a program
> that was in a loop appending to a long string. Turns out that VFP
> appends by allocating a new mem area, copying the existing string, then
> appending the added chars. I still suspect the addtolist() method,
> whatever it's called, is where the time is going.
>
> Short run, running from a server gets you off the hook. Long run, I
> think we need to find a better way to populate that list. Maybe from an
> array?
>
> Dan Covill
>
>
>
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/4d705677.2050...@ggisoft.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
