LiveCode Forums.

If I create an stack with 100 cards and another stack with 10 cards and 9 substacks, each sub-stack with 10 cards (so 100 cards total). All of the cards are identical to those in the other app, which one would use less memory?

For organization and maintenance having the sub-stacks will be easier.

Linda

What's on the cards?

What's on the cards?

Does that matter if the individual cards would be the exact same (theoretically) in each app?

But there would be buttons, lists, fields, etc. Card for card they would be the same in each version.

If there would be little difference in the memory required, it makes sense to have many substacks so that I can better organize the app for future development, maintenance, bug searching, etc.

Linda

Logic dictates that a stack with sub stacks uses more memory. However, it probably is only slightly more. You could test it yourself.
Why do you ask?

Regards,

Paul

Because I literally will have hundreds of cards in an app for veterinarians for diagnosing diseases. It is following line graph algorithms to finally drill down to a list of diseases based on the symptoms or diagnostic tests performed.

For instance, Fever. There are so very many causes of fever.

If I put all of the cards for "Fever" in one stack, it would be far easier to alter just that one stack than it would be later to wade through hundreds of cards that would be, essentially, about a different subject.

Hopefully, this makes sense. I can definitely test it out myself. I assumed that it was something that others had already gone through this decision making process...to have substacks or not in order to keep an app's size as small as possible, especially for handheld devices.

Thank you,
Linda

anmldr wrote: ↑

Thu Jun 04, 2020 7:55 am

What's on the cards?

Does that matter if the individual cards would be the exact same (theoretically) in each app?

It might, if there were a lot of images, or large amounts of text, or other things that could consume a lot of memory. In some cases you can shuffle stack files in and out of memory, but if it's small enough it won't matter.

But there would be buttons, lists, fields, etc. Card for card they would be the same in each version.

If there would be little difference in the memory required, it makes sense to have many substacks so that I can better organize the app for future development, maintenance, bug searching, etc.

If the media content in the stack is minimal, go for ease-of-development.

Gracias.

Linda

I made an epub reader for my own use. My first attempt coming from my hypercard days was constructed having a card for each page of text. There were shared controls on the cards and it seemed a simple way to go. When I did this and loaded my epub (1,500 page book) it was glacial. Simply going to the next page was visibly slow. LC is not the same as HC in this regard.

I then chose to have only cards for each different view and instead of loading the book into a card a page, loaded the book into an array (and then into a sqlite db.) Now the app simply grabs the required text for each view and loads the appropriate fields. From a users perspective this is effectively instant.
If your cards and nearly identical then I would really suggest having your data in variables and loading the appropriate card to display its data.
Then, instead of a main stack and 10 substacks you could have a mainstack and 10 cards.

In my app I read the epub into a set of arrays (determined by the structure of epubs.) and then wrote the content, from the main array, in to database which used sqlite’s full text search. This provided me with the ability to carry out complicated searches and display search results as snippets etc.
You may not need to use a database for your app, maybe text files to start and variables/arrays saved with the stack to continue.

But my point is, you really may not need all the cards you proposed. Script actions on variables are soo much faster than similar actions on fields and cards.

James

I agree with James,

I also use arrays for data retention and retrieval. I put a few command scripts in the stack, each card and each field. After this I can add a field, just copy the code from another (or just copy/paste an existing field). The data in the field is instantly saved when someone ads data into the field and the field will be filled when the card is opened. The array with the field information is filled as soon as the stack is opened and saved when a field has changed (can be encrypted as well).
I have made an example stack of this. Take a look at the code in the Stack, Card and Fields.

Hopes this helps to speed up your application(s).