What's your _VFP.AutoYield setting? It should probably be .F., at least for the code around the OCX adding data code. Maybe those settings are different between the IDE and the runtime?
Fred On Thu, Mar 3, 2011 at 8:03 PM, Mike Copeland <mlcopel...@gmail.com> wrote: > 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/aanlktik7cd97akqiecxsp_zez8qoyjv2e3jfcezzp...@mail.gmail.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.
