Column ordering - does it impact speed?

Ask for Help
1

My ‘user profile’ table is about 400 columns long (maybe more). I have strings and lookups for each user, as I have to use row owners (for data privacy) so I need to pull in everything I need in the app into the user profile (in my app this is called CollectUser).

My app is made of tabs - 4 onboarding tabs, then the functionality tabs. I use CSS to remove top and tabs to control the user experience.

The first tab that is visible is based on usc-hasProfile is not true. The user gets their profile complete after the end of the onboarding process.

The weirdness though… for existing users, they would see the onboarding splash screen first for a second or two, before dropping into the Home screen (visible if hasProfile is true).

So I made two changes:

  1. moved the Home to the first tab on my list - so glide will resolve to that first in any case (and new users do not have the value set, so they will not see it, maybe wait a fraction of a second, but no screen flash)
  2. I moved the usc-HasProfile column to the second in my table (after the row ID)

I was thinking that Glide computes column-by-column, so things I need accessible quickly should be at the front of my table (i.e. closer to the left than the right).

Question — is this a correct assumption?

Thanks!

2

Hello sir,

  1. Glide editor has a search bar, in case it has escaped you.

  2. It’s really a question of convenience as your post hints at. Having the columns you use the most at the top helps to quickly find stuff, create rel and what not. Bar this convenience exception you can put your data columns or computed columns in any column you please. They are nothing special. The terminology is somewhat unfortunate but that’s not my problem.

Thank you

3

It is not about me finding the columns :slight_smile: :slight_smile: :slight_smile:
It has to do with speed of accessing the data from the user side.

So I understand your answer… and it is correct in terms of the convenience for the Glide designer - but that was not my question :slight_smile:

Mine was for app users… if you have a heavily trafficked app, every second counts. Every time you can avoid touching a GSheet counts. Every unused computed column. Every lazily written if-then-else that takes longer than needed to resolve for most cases. Etc, etc, etc :slight_smile: :slight_smile:

4

My answer still applies. The end user has no direct exposure to or interactions with the Editor or Gsheet. All they have in their hand is an app. Speed is not affected by anything you do in the editor. When glide tells us that using glide tables (if they can be trusted to do anything at all)has certain advantages over the sheet, they are correct, but that’s neither here nor there in the overall scheme of things as ultimately everything depends on the speed of your net. Where speed is not an issue and you are using tables you don’t need to worry about syncing issues whereas with sheet it’s the lifeblood of the app. Another thing though that’s often missed, syncing has nothing really to do with internet speed.

Thank you