Beach ball on Mac

[Laurent]

Dear Brendan,

On my Mac (Air, 1,6 GHz Intel core i5, 4 Go memory, 32 Go free HD).
I recently added a form (called “mtm”) with 5 many to many relationships fields to my other forms (called “1”,”2″,”3″,”4,”5″).

When I switch to mtm I get the beach ball for at least 5 seconds, then mtm appears, same when I switch back to 1 to 5.

I have no beach ball when I work on 1 to 5

I have no lag issue when I do the same on my iPhone 5s or iPad Air, all in sync.

My DB is about 1500 records for 90 Mo. I already did the maintenance routines (compress, clean, …) but to no avail.

Thanks a lot for your feed-back,
Kind regards,
Laurent

[Brendan]

Hello Laurent,

Improving the performance of Tap Forms is definitely high on the to-do list for this year.

Do you have any calculation fields or are you displaying one or more aggregate calculations? And are you viewing your records in single or multi-column list view?

Thanks,

Brendan

[Laurent]

Hi Brenda,

Thanks for your feed-back.

Only one calculation field (sum), only one aggregate calc. displayed, single column list view.

Hope this helps,
Thank you.

[Brendan]

Hi Laurent,

Does this happen only when you double-click on a linked record? And if so, does it happen if you just click on the linked form directly from the forms list without first going through the parent record?

Thanks,

Brendan

[Laurent]

Hello Brendan,

The beach ball happens when I first click on the mtm form, in the form list, before I can see the records there (actually only 2). Then, when I double-click on a linked record in mtm the switch to the original record is instantaneous but when I want to go back to mtm by clicking the back arrow then I got the beach ball for about 5 seconds.

Thanks a lot and nice day!

[Brendan]

So there’s something about this mtm form that’s causing the problem. By “mtm”, do you mean “many to many”? Is this the main parent form? And it causes a beach ball with only 2 records in it? I’m just trying to understand clearly.

Can you please email me the form template for the parent form?

Thanks,

Brendan

[Brendan]

Hi Laurent,

Another customer of mine had a similar problem and sent me a backup of his database to test with. I was able to reproduce the problem on his database. For me however, the app locked up completely after I clicked on the back button. I then tested it using my current development build and it did not happen there, so I believe I have fixed this problem.

Thanks!

Brendan

[Laurent]

Hi Brendan,

Thanks for your answers, good to hear that this might be fixed in the next update.

Yes mtm form is the form containing the many to many relationships records (linked to 5 parent forms). I am sorry, my DB is professional and I am not allowed to share the info it contains… However I will try to email you a screen shot of the DB structure.

Thank you!

[Brendan]

Got it, and the form template. Thanks!

No beach balls so far.

[Laurent]

Dear Brendan,

I have just updated to 2.2 on Mac but still got the same beach ball issue as described in the previous posts of this topic… The lag is still the same. Moreover some lag has been added when I switch from one form to another (most evident when I switch back to the most populated form (about 700 records).

By the way, where is 3.8 for iPhone & iPad? As planned the sync is broken with 3.7.1.

Thanks a lot for your feed-back,

Nice day,

[Brendan]

Hi Laurent,

Have you tried it on the multi-column list view?

Also, I find that running through the database maintenance tasks really helps to speed it up. Try that. Do the Vacuum, then Analyze, then Rebuild Indexes, then Rebuild Search Index. It’s in the Preferences screen under Database Maintenance on the Mac version.

Thanks,

Brendan

[Laurent]

Brendan
Single column list view
All maintenance tasks done
Sync enabled

2.2 introduced new lags and is now a pain to use.

I am disappointed

Hope you will find a solution
Thanks!

[Brendan]

Hi Laurent,

Can you please try multi-column list view mode to see if that is any better?

2.2 shouldn’t have introduced any new lags. None that I’ve seen yet.

Thanks,

Brendan

[Laurent]

Brendan

The new lags appear when I click on forms containing 700 to 900 records : it takes more than 5 seconds for the records to show off. Clicking on forms with about 200 records do not show any lag. Before 2.2, I had May be a 1 second lag when I clicked on the 700 – 900 records forms. I will try the Multi column view and let you know.

Thanks !

[Brendan]

Hello Laurent,

One issue with the single-column list view is that it now calculates row heights dynamically. So Tap Forms must go through every record and fetch the data for the first X number of fields (however many you have set on the List View Fields setting) then determine based on that content for each row, how tall the row should be. With the multi-column list view, it doesn’t have to do that because all rows are the same height. So it will be faster to display.

Thanks,

Brendan

[Laurent]

Hi brendan

Thanks for your tip, the multi column view removed the new introduced lags when clicking to high number of records forms. Nevertheless the lags reported on my first post here above are still there.

I am not fond of the multi column view, is there a plan to go back to an acceptable lag in single column ?

Thanks,

[Brendan]

Hello Laurent,

Tap Forms re-computes the row height for every row in your form when in single-column list view. I will need to use a caching system to speed that up on subsequent clicks.

Sorry for the lag.

Thanks,

Brendan

[1Levite]

Another vote for speed….

There is an astonishing difference between the single column view and multiple column view refresh speeds on my systems. I have an old 2007 iMac Core 2 duo [skimpy 2 GB memory] (Mountain Lion) and a late 2013 Macbook Air loaded up with RAM goodies and Mavericks. Both have identical data and TF 2.2. Forms include one with about 300 records linked to another form with about 9000 records with inverse relationship. No calculations, but pretty text intensive.

Some rough update comparisons when switching to the form with 9000 records are below. The forms have been vacuumed, analyzed, rebuilt, etc.

iMac, single column view with one list view field: up to 10 minutes to update
iMac, multiple column view: about 7 seconds

Air, single column view with one list view field: about 1.5 minutes
Air, multiple column view: about 1 second

The single column view with list view offers some great flexibility, but is a little too pokey for my forms. I’m OK with the multiple column view for now, but will look forward to a peppy single column view down the road. Still hands down a great app.

[Brendan]

Hi 1Levite,

I have made the single-column list view operate much quicker for the next update.

In a test that I just did on a 9,000 record form (although with only 4 fields), it took 4 seconds to display in multi-column list view. And about the same in single-column list view. That performance improvement does come with a price though. Scrolling in single-column list view might not be quite as smooth as it was before. Plus for some records the row height calculation isn’t as accurate as it was before.

I develop Tap Forms on a MacBook Pro with 16 GB of RAM and a 768 GB SSD for storage. The SSD is blazingly fast though, so that has a huge impact on performance. But still, the performance improvement I’ve made to single-column list view is noticeable.

Thanks!

Brendan

[Laurent]

Hi Brendan,

Just a quick word to say THANK YOU!!! The last 2.2.3 Mac update definitely solved the lag issue I and with the single list view!.

Keep up the very good work.

Once again thanks a lot!

Nice day to you,
Laurent

[1Levite]

HUZZAH! HUZZAH!

I have to report that TF Version 2.2.3 (522) should remove all concerns about speed and beach balls. Here’s an update from previous posting with an informal unscientific speed test.

Two systems with identical databases. (1) 2007 iMac Core 2 duo, 2 GB memory, (Mountain Lion) and (2) late 2013 Macbook Air loaded up with RAM goodies and Mavericks.

First time trials under TF 2.2 were with a Parent form with about 300 records linked to Child form with about 9000 records with inverse relationship. No calculations, but pretty text intensive. Today, running TF 2.2.3 the forms have about 310 and 12050 records respectively, since I added some data.

TF2.2 with 300/9000 records (Original Trial for updating the 9000 record form)
iMac, single column view with one list view field: up to 10 minutes to update
iMac, multiple column view: about 7 seconds
Air, single column view with one list view field: about 1.5 minutes
Air, multiple column view: about 1 second

Now, hold on to your hats:
TF 2.2.3 with 310/12050 records (updating of the 12050 record form)
imac, single column view with two list view fields: <5 SECONDS to update.
imac, multiple column view: 3-4 SECONDS
Air, single column with two list view fields: <3 second update
Air, multiple column view: less than 1 second
A HUGE performance improvement for the single column view.

PLUS…TF 2.2.3 startup is just as peppy.

Kudos to Brendan for sorting this out. Well done!

[Brendan]

You will also unfortunately notice that the row height for each record is the same for every row now. That was one of the tradeoffs I had to make to gain the performance back. In the previous version, Tap Forms would size each row so that it fit the data. Now I have to make each row the same height. The height of the rows is determined by how many fields you’re displaying on the records list view (the List View Fields setting).

There were 2 reasons why it was so slow before:

1. I had to add code to the SQL database query to fetch the first “List View Fields” count number of values for every record in the form. That slowed the initial query down.

2. For every record in the form I had to take the “List View Fields” count worth of data and do a calculation on it to determine how tall to make the row in the single-column list view. It was based upon the size of the fonts used to generate that view.

Both of these things had to be done before the data was displayed unfortunately. So that meant that if you had 12,000 records in your Form, Tap Forms would loop 12,000 times when fetching the records from the database in order to create objects, plus another 12,000 times to determine the row height of each record in the list view table. So…. a TON of work. But now it only has to fetch the 12,000 records from the database and loop through the data once to create objects. The row height is now statically determined based upon the number of fields you have chosen to display.

Hope you didn’t mind reading about the technical details behind the curtain :-)

Thanks!

Brendan

[Brendan]

Oh, and here’s another interesting tidbit of information…

On the iOS version, I can still calculate the row height dynamically based on the text content of each row and not lose performance. That’s because iOS has a function which can estimate the height of the row and then determine the calculated height of the row only just before it’s about to be displayed. The API is called estimatedRowHeight… There’s no such method on Mac. I spoke with the Apple engineer who works on the Mac’s table view code at WWDC this year to ask if he could add an equivalent estimatedRowHeight method to the Mac. So I’m crossing my fingers he can do that at some point.

Thanks!

Brendan

[1Levite]

After I posted the updated time trial, I thought it would be interesting to see if the update time was dependent on the number of fields in the List View Fields setting. It wasn’t. The update time was essentially the same whether I selected one field in the single list view or five. Your “behind the curtains” comments explains why that is the case, I think.

You mentioned in a previous post that the scrolling of the single list view might not be as smooth, and I did notice that with every scroll, the hard drive on the old imac is doing something (no noticeable difference on the macbook Air scroll). I don’t remember what it was doing on the scroll before 2.2.3. I can live with these trade offs though.

[Brendan]

Tap Forms is fetching the data to display as you scroll. The more fields you display, the more data it has to fetch. You don’t notice anything on the Air probably because it has an SSD drive and you can’t hear that operating. But it is :-)

[Author]

Posts