lcTaskList Performance

[Michael Doub]

Paul,

That would be of interest to me.  What do you have cooking?

-= Mike



On May 25, 2012, at 12:27 AM, Paul Looney wrote:

> Peter,
> 
> Suppose there was a database built with LiveCode, that required no SQL, that worked with your data, that made your data multi-user, that provided encryption for the network, that ran really fast, that let you tweak your data and interface as you wished?
> 
> Would this interest you?
> 
> Paul Looney
> 
> On May 24, 2012, at 8:16 PM, Peter M. Brigham, MD wrote:
> 
>> On May 24, 2012, at 6:36 PM, Paul Looney wrote:
>> 
>>> Bill,
>>> 
>>> I've been following the RunRev list comments about lcTaskList speed.
>>> 
>>> For what it is worth
>>> 1. I have 46 large stacks open on my desktop (just for testing, I don't work this way)
>>> 2. Some of these are substacks, most are main stacks
>>> 3. I have two large, 2000+ lines, stack scripts open in the Script Editor
>>> 4. The largest stack has 510 fields and 282 buttons
>>> 5. The largest stack script is 2327 lines of code
>>> 6. I'm guessing that, in open plugins, substacks, btns and flds, there are over 100,000 lines
>>> 7. I'm testing with and without the script editor open and the message box displayed
>>> 8. The TaskList is correctly displaying 23 FIXMEs
>>> 
>>> Updating the TaskList is almost instantaneous - too fast to time - certainly less than 2 seconds. Could not ask for better!
>>> 
>>> MacBook Pro, 2.2 GHz Core i7, 4 GB 1333 Mhz DD3, OS X 10.7.4
>> 
>> I'm guessing that the reason for the discrepancy between your case and mine is that my main stack has 700+ cards, so Bill's plugin has to search over 200 controls on 700+ cards to index the scripts, plus the 44 other stacks. I know, I shouldn't be storing data in individual cards, I know....
>> 
>> My stack system, Psychopharmica, is the way it is because I started the whole thing over 20 years ago in Hypercard and had a card for every patient, and I continued that model through my RunRev/LiveCode transition, not appreciating the importance of separating data from GUI. I have continued this antiquated structure for several reasons: my customized search routines depend heavily on HC/LC's find and mark commands, which are blindingly fast, and to try to duplicate even some of the functionality using database searches would be prohibitively labor intensive -- I really don't have the time to learn SQL commands given that I already have three half-time jobs. Not to mention all the other wrinkles I would have to iron out to change to a database-centered system. I know I have painted myself into a corner here, but my system has worked so well up to now and is so complex that making the paradigm shift is overwhelming.
>> 
>> Plus there is an even more compelling reason for not putting energy into the necessary changes. If I were in a position to devote more time to it and it had a future that could be ported into a commercial venture, I'd tackle the job, but everyone in the medical field is moving towards electronic medical records and my system was designed from the beginning to print hard copy paper notes for a paper chart. To move this thing into an electronic medical record system would require me to learn networking and encryption along with the database management (not to mention developing an intimate familiarity with the HIPPA laws regarding medical confidentiality). I am essentially just a (pretty experienced) LC hobbyist with another profession that I have used LC to support, not a real IT person. I'm not prepared to create an entire EMR system single-handedly.
>> 
>> So the end of the usefulness of Psychopharmica is heaving into sight. My group practice is about to adopt an EMR system this summer, so I will not be able to use my own customized LC system any more. I am not looking forward to having to use a piece of software that I can't tweak at will to make it do exactly what I want it to, and I'm preparing myself for daily cursing as I use the new software. (The two other psychiatrists in the practice that use Psychopharmica are also feeling bleak -- they appreciate how nicely this software is attuned to the actual workflow of a busy practice, and it's about to die.)
>> 
>> Sorry for the long, tangential, and somewhat bitter aside -- I didn't start out this post thinking that I'd write all this. I guess I'm in mourning already and needed to vent. It's been 20 years now that I've been spoiled by having a truly perfect tool -- one that evolved with my needs, not someone else's. Now it's time to say goodbye.
>> 
>> ;-(
>> 
>> -- Peter
>> 
>> Peter M. Brigham
>> pmbrig at gmail.com
>> http://home.comcast.net/~pmbrig
>> 
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode