Speed of moving from Card to Card

[hilton]

Hi Folks,
(Livecode 7.0.2-rc-2)

I have an app that has 19 cards about 8000 lines of code.

It was performing ok when going from card to card whether in the IDE/windows standalone/android standalone. At some point it suddenly slowed down and it takes 7 seconds to swap from card to card in the IDE and windows standalone. Android is ok, it takes about 1 second to move to another card. I have tried to isolate the cause but have failed. I have eliminated all code between "go to card" and "opencard" and it makes no difference.

Once you have loaded a form the performance is fine.

The other thing I have noticed is that the Android standalone is very large - some 24mb.

Unfortunately, I have not been able to see what is causing the delay (so that I could advise quality control). I was wondering if anyone else has come across this and found a solution.

I will keep looking and if I find anything I will advise you all, just in case someone else has had something similar.

Thanks,
Hilton.

[jacque]

That's a very long time for a card change. What sort of form are you loading?

There is a big slowdown in LC 7.x when doing any type of text processing (RR has found at least one of the bugs that causes that and will be fixing it.) If your form requires processing text in any way, you will get much faster results using LC 6.7.

The increase in the app size is due to the unicode libraries that are attached in LC 7. Building in 6.7 will create much smaller apps.

[hilton]

Hello Jacque,

I am not sure what you mean by "type of form", however, each form has a common Header with an HELP image, a title and a MENU image.
There is also a common Footer with 3 labels, 2 for navigation and one for a date. The Header and Footer are each contained in a Group.

There are two forms for each subject, one contains a datagrid (table not form) and the other form contains the detail fields, buttons etc. There are about 10 to 20 labels/text fields/buttons on each details form. All of the fields are always contained in a Group and the Group is generally larger than the form for the Detail fields which forces a scrollbar(this is so that on Android you can scroll the form up and see what you are keying in when the Android keyboard is hiding fields).

I tried lc6.7 but it said my plugins were not stacks whereas lc7 thinks they are stacks. However, to follow your advice, I will recreate the plugins in 6.7 and see what happens.

Thanks for your interest,
Hilton.


PS I have just managed to get 6.7 to swap from card to card and it is faster, however, it still takes some 4 seconds.

[jacque]

Depending on how much data you're working with, it might be the datagrid. If you're only using the table form, you could probably just replace it with a regular field and a little scripting. But to make sure, try removing the datagrid (work on a disposable copy) and see if navigation speeds up. If so, then that's the problem and we can go from there.

[hilton]

Hi Jacque,

I removed the datagrids as you suggested, but no change in speed.

I then decided to:
A. remove about 13 cards worth of functionality, just to cut down the size - no change in speed in IDE
B. remove the plugins and make them substacks - no change in speed in IDE

I created a windows standalone and it is faster now, but still takes about 3 seconds to move from card to card.

I put a message just before "go to cardxxx" and beeps(3) in the preopencard of the destination card and it still takes about 7 seconds in the IDE to get to the beeps before opening the card.

I tried to use livecode 6.7 but it does not like the 7.0.2 file and says that it is not a stack.

Well, that's it for now - maybe I will have a bright idea while I am asleep tonight.

Bye,
Hilton.

[jacque]

LC 7 uses a different file format that earlier versions don't recognize. To open the stack in version 6, choose Save As from the LC 7 File menu and choose 5.5 as the legacy format in the popdown button. The resaved files should open in version 6.7.

If removing objects isn't helping, post the relevant navigation handlers and we can see if there are any obvious slowdowns there. It sounds like something is going on in the closeCard handler.

[hilton]

Hi Jacque,

I know it's been a while, however, this is what I have done:

1. re-written the app using v6.7
2. run it as Android and Windows app and card changes take about 1 second (faster on Android)
3. compiled the app using v7.0.0-rc
4. run it as a Windows app and card changes are slightly longer than v6.7 but acceptable.

When I was using v7 rc2 I had a couple of instances where it would not load the app for editing as it claimed that the app was corrupted. In fact a few things happened that I could not trace and when I went back to backup , continued and the problem disappeared. At this point I can only assume that something went wrong with the code for closing a card (maybe corrupted). I am not going to spend more time trying to figure it out, however, I would like to thank you for your interest.

Regards,
Hilton.

[hilton]

Hi folks,

Over the past number of weeks I have (at Jacque's suggestion) been using v6.7 and things were ok. I wanted to keep up to date and so moved to v7.0.4 and generally speaking all is fine with the exception of moving from card to card.

At present in the IDE it takes about 8 seconds to move to another card. The app contains 8 cards that are used during navigaton from one user function to the next and another 5 that contain code that is for functions and standard code that is only copied during "development". I would guess that the app contains approx 15,000 lines of code.

The speed of changing cards on my phone (Android) is less than 1 second, which makes me happy. I decided to try the app compiled as a Windows app and found that changing cards takes 4 seconds, which makes me very unahppy.

I found that if I reduced the number of cards in the app the IDE sped up considerably (as one would expect).

Just for the fun of it I wrote some code in a hidden button that runs through the app and splits it into 8 apps to be used in Windows. I then compiled some of these and once the initial "menu" card was loaded moving from function to function was very quick (if the platform is "Win32" I used launch although I did see that some folk prefer shelling).

All of the above made me wonder if I was using the correct approach to constructing an app.

Should it all be one large app?
Should it be split up into smaller apps?
What is the strategy used by experienced developers (or those smarter than me)?

I am in no desperate hurry as at present my main interest is Android, but I would like a version that runs quickly in Windows. Of course, any improvement in IDE speed would make development less frustrating.

Any suggestions would be appreciated.

Many thanks,
Hilton.

[dunbarx]

Hi.

I keep wondering about those 15,000 lines. That is a fair sized chunk of code. Is it possible that a lot of stuff is being processed before any navigation commands finally come up?

Craig Newman

[SparkOut]

Yes, and do you have anything in the close card script? Is it storing the datagrid content in a database, for example?
Is there anything among the pending messages that could be flushed?
Oddly, I have just been experiencing an issue with 7.0.4 and 7.0.5 where everything was fine and instant in the ide but changing cards or running one particular script on the actual android device slowed to impossible speed (10 minutes or more).
I edited the script and inserted a line - put the seconds into field " fldDev" - in between every genuine line of code, to see where the script bogged down or if the whole thing was slow all the way through. It started working well again, so I took those lines out, and it still ran well. I wonder if there is some factor in the instability of versions 7.0.x that is affecting script processes. I obviously have no recipe to reproduce symptoms. I am seriously hoping 7.0.5-rc3 will be an improvement.

[jacque]

I keep thinking about all that script too. That's a whole lot of code and usually things can be shortened when it gets that large. But one test to see if it really is the scripts is to comment out the entire stack script (and possibly some of the card scripts too) and see if navigation speeds up when using the View menu in the IDE to move between cards. If so, it's the scripts.

One major difference between LC 6 and LC 7 is how it handles text. If the scripts do a lot of text parsing then it's likely to be affected. Even without the parsing though, some things just take longer in version 7. But they shouldn't take as long as is being reported.

The cards should definitely all be in the same app. Even if you want to split them out into separate files, the extra files should be stacks, not compiled apps. But you shouldn't need to do that and it would be a clunky workaround.

[FourthWorld]

I wonder what real-time logging of messages and resulting handler triggers might reveal.
http://fourthworld.net/revnet/devolutio ... der.rev.gz

[hilton]

Good Morning everyone,

The app is a relatively simple Estimating and Job Costing system for small contractors and builders. For each topic(eg Vendors, Customers, Estimates etc) it generally consists of a datagrid listing items in the topic (eg customers) and a related details group which contains the contents of any item selected in the datagrid. The grid and detail goups are controlled by a tab page button. Each topic has it's own card. That's some background. Very little text processing is performed.

Ok now for what I have tried.

1. put a message prior to the Menu "go to card ??????" and a message in the preopen handler of the destination card and that's where the time is taken up.
2. commented out the mainstack and navigated using the View Menu. No improvement.
3. commented out the mainstack, menu and customers. Using the project browser to go to and from those two specific cards. No improvement.
4. during the process of commenting out a cards script (ctrl-A to select all, Edit>Comment) I happened to notice that one of the cards took a while.
5. with that observation I decided to uncomment the couple of cards that I had commented and then restarted the process timing a couple. The menu card which has 130 lines was quick, so did not bother to time. The Customer card was next and took 1min for 1227 lines. The quote card was next and that took 2min 45secs for 1460 lines. The jobs card was next and that took 2min 15secs for 1345lines. Very tedious.

Talking about the standalone win32 version, it is only card swapping that is tedious. Once at the destination everything is quick - datagrid, writing, changing, deleting. With the datagrids I never read all the data, only one page at a time and it is very quick.

As I said Android is fine in all respects.

Bye for now,
Hilton.

[hilton]

Hi Folks,

I have at last found out what was causing the slow swapping of cards. In the IDE it has gone from 13seconds down to less than 1sec.

I started learning with v7.0.3 rc and it was buggy and caused corruptions.
On Jacque's advice I went back to v6.7 (or whatever) and the speed was bearable.
I then went to v7.0.4 and then v7.0.5 and the speed became unbearable in both.

In the end I discovered that by creating a new mainstack in version 7.0.5 and then copying all the cards into this new stack from the old tedious one the speed improvement was realised. Hopefully, anyone else experiencing the same will find the above works.

Bye,
Hilton.

[FourthWorld]

In the end I discovered that by creating a new mainstack in version 7.0.5 and then copying all the cards into this new stack from the old tedious one the speed improvement was realised. Hopefully, anyone else experiencing the same will find the above works.

Glad to hear you've found a workaround, but I'm still curious about the root cause. Is there a substantial difference in file size between the original and rebuild stacks? Are all libraries and behavior scripts in place in the new stack exactly as they were in the original?