Application with many cards running extremely slowly.

[Drachen Jager]

I'm building an application with lots of cards. When I finish it will be in the region of 750. Right now I'm hitting about the 350 mark and Revolution is getting slower and slower with each new card I make. Even switching between cards, which used to take under a second is now up in the 20-30 second range.

Is there anything I can do to optimize things?

[Mark]

Drachen Jager,

Is there anything I can do to optimize things?

Yes. Change your strategy. Make an application that doesn't need so many cards. What you are doing probably doesn't make sense.

Why do you think that you need so many cards? If you can explain that, it might be possible to help you with a different strategy.

Best,

Mark

[Drachen Jager]

There's no real getting around the number of cards required. One possibility I'm trying to figure out now is how to hold all of the basic card scripts in one place, because I have some menus and then 10 cards which are repeated around 70 times each with only minor changes. If I could hold the scripts that each of the 70 cards has in common for each of those 10 cards in say the stack script file and just access them with a simple string each time it would massively reduce the number of lines of code.

[Mark]

Hi Drachen Jager,

There's no real getting around the number of cards required.

Why do you think so?

Best,

Mark

[Drachen Jager]

I need to use 700 or so cards because I'm creating an educational application, there are 10 lessons per subject and 70 subjects.

No there is no way to put multiple subjects together.

No there is no way to put multiple lessons together.

[Mark]

Hi Drachen Jager,

Most educational applications need only one stack with one card. Often, a few optional stacks are added, for example to show a splash screen and a help screen.

I'd recommend to change your strategy. Perhaps you should tell a little more about your stack.

Best,

Mark

[paul_gr]

Hi Mark,
In the list archives, some posts mention using thousands of cards, so I assumed that using hundreds of cards would not be a problem. Drachen probably came to the same conclusion.
I have a tuition application with 400 pages (cards) that I would like to rebuild using Rev Studio.
I have used Director to make educational standalones, and 400 screens (cards) are not uncommon when they are designed to replace a book, or series of books.
What kind of strategy would you suggest if I wanted to build similar projects using Rev, or would you not recommend using Rev for this kind of work?

Paul

[Mark]

Hi Paul,

I would use one card or possibly one card for each lay-out. Of course, now you will say that every screen has a different lay-out, but then you need to reconsider your design.

Keep your pictures, sounds movies and other materials on disk. Don't embed them in the stack if you don't need them continuously. That will save you a lot of trouble.

Everything else depends on the kind of project you want to make. If you have specific questions, I'll be glad to answer.

Best,

Mark

[paul_gr]

Thanks Mark,
I appreciate your opinion.

Paul

[whelkybaby]

What about using groups to collect multiple controls together and then showing and hiding the controls as needed?

This is the approach that I'm likely to take with a possible monster project. The data to be collected in this one really does give rise to a unique layout each and every time.

Cheers,


Steve

[cosrusso]

A Livecode project with many cards (over 700) can be common in gaming as each card can act as a 360 degree node. Livecode is now REALLY slow on a iOS 7.1 standalone, but was not slow in iOS 5.1.
Is this due to Livecode's internal storage of card elements in iOS? This is no longer efficient and will only get slower with new iOS versions. I hope I am wrong.
The idea of using a single card and changing the card elements to suit each node is fanciful - it would be a coding nightmare. Surely the main architecture behind Livecode is the "card" - have as many as we need for the job.
Is there a solution to Livecode's slow performance in iOS 7.1?

[zaxos]

One possibility I'm trying to figure out now is how to hold all of the basic card scripts in one place, because I have some menus and then 10 cards which are repeated around 70 times each with only minor changes

how about make functions for this code instead of repeating it? maybe if you post some of your code we can help you.

[cosrusso]

The original game was made with Revolution in 2004, and ran smoothly with over 700 cards on PC and MAC. I find it frustrating that 10 years later, the same game (adjusted for iOS livecode) runs slower than programs running on a 90's computer
I won't pay for another Livecode licence until fixed.

[jacque]

A lot of changes have occured in 10 years, it's reasonable to expect some recoding after all that time. Also, iOS is a different OS with different requirements, CPU speeds, and response rates, so a direct comparison with desktop systems isn't always valid.

[cosrusso]

The issue I was having is not due to having over 700 cards at all. After hours of investigation (deleting cards, removing copy files, and anything I thought would cause slow downs), it is the "Quality" setting in "Basic Properties" of the inspector for images that was the culprit. In previous versions of Livecode, a setting of 'good' or 'best' posed no problems, but in Livecode 7 and iOS 7, a setting of 'good' or 'best' can delay redraws by 1 second!
The disadvantage is that I need to leave my images set to 'normal' - giving up on image quality so I can get speed performance back...?