Slow stack problem

Neville Smythe neville.smythe at optusnet.com.au
Wed Jun 26 04:35:36 EDT 2024


I am plagued by a new problem which has arisen in an old stack that I have been using for years with hundreds of modifications over that time. It was still working well until suddenly in the last few week most of its data processing handlers have slowed to a crawl. A button that gathers text data from a number cards, does some text manipulations and then displays a modal dialog, that used to be instantaneous now takes 30 seconds to display the dialog. Another button which does extensive text gathering and processing now takes 30 minutes instead of 30 seconds.

So I have done something to the data stack in the last few months. It is not a change of LC version or platform OS. A standalone I produced a couple of months ago does not display this slow behaviour when working on its old version of the data stack, but does show it when I apply it to the latest version of the data stack.

But I am at loss to figure out what setting I might have changed or what else I could have done. I did not change the scripts of the offending buttons since the previous version, so it sounds like a setting change. The stack behaves as if the processing buttons have difficulty finding all the necessary handlers, or as if it is it reporting in to Shanghai or Virginia between handler calls. I don’t believe the stack is actually corrupted, actions such as scrolling fields or moving between cards all work as normal. The only other piece of information is that the CPU ramps up to 100% use in one core , so it is doing something - but what? (Memory usage goes up to 500MB but does not keep climbing, unlikely to be a memory leak or virtual memory swapping (hmmm?))

I have tried to compare the differences between the old and new version of the stacks as files using BBEdit, but most differences seem to be in  binary data at the end of the files, whose meaning is opaque.

Any ideas as to what might be causing this, or how I might go about diagnosis, would be hugely welcome.


Neville Smytis






More information about the use-livecode mailing list