Please help me save my doc

[nate_hurst]

Hi All.

I’ve been working on creating a coda app for GTD purposes over the last year or so. The version I’m working on now has worked great until yesterday. I’ve even tried reverting back to other time periods but the times are still slow. I checked it on another computer and same issue.

If you could, would you please take a look at my document and test adding anything to the inbox. It might take a couple times before it will lag, but it will. I’m getting calculating time in the 40s-1m range and I can’t for the life of me figure out why.

I’ve deleted most of the data in here for privacy, so the times might be different, but you should still be able to see the culprits.

Here’s a link… thanks so much for any insight.

ALSO: it seems like this only occurs when I am adding a new row… Does the entire table recalculate every time a new row is added?

[Federico_Stefanato]

Hi @nate_hurst ,
I just took some time to have a quick overview of your doc.
You actually did a great job and it’s impressive the sophistication level you put in place.
I tried to find out where most of the time is spent, by using the debug tool:

I think that being 99% a self reference lookup, the Datastream table will inevitably degrade performance as records increase.

Couple of basic questions (I’m sure you asked already yourself):

1. Are all the columns necessary?
2. Can something be computed manually/or event based?
3. Is there any value that can be set as default value from computation (rather than a formula)?

I would then proceed to divide row-only-based formulas from table-based formulas columns and start looking at the second ones.

@nate_hurst

Does the entire table recalculate every time a new row is added?

In the latter case, yes.

I hope this helps.
Cheers!

[nate_hurst]

Wow, thanks for the compliments and insight.

There definitely seems to be an issue with the lookups. When you say a self reference lookup, do you mean referencing a column within the same row ?

1. Are all the columns necessary?

• definitely not. working on condensing them. Trying to work out a way to not have pass through tags on everything. That will reduce some clutter hopefully.

2. Can something be computed manually/or event based?

• I tried using automations in some areas but the response time wasn’t instant on “row changed”, and it drove me nuts.

3. Is there any value that can be set as default value from computation (rather than a formula)?

• would you mind to give me an example of what you mean ? or a suggestion on the table of what could be computed rather than formula?

4. Row based vs. table based.

• An example here would be appreciated too. I think you mean same row lookups vs table lookups, but I’m not sure what to do with the table based ones.

Just read this again… Do you mean that everytime I add a row the entire table is being recalculated because I have table based lookups?!

[Federico_Stefanato]

Hi @nate_hurst

@nate_hurst

definitely not. working on condensing them

Great: get rid of everything that is currently not necessary.

@nate_hurst

… but the response time wasn’t instant on “row changed”, and it drove me nuts.

I know what you mean. Sometimes there are one-off actions that can be put in a button and triggered once in a while. I understand it’s not your case, though.

@nate_hurst

would you mind to give me an example of what you mean ? or a suggestion on the table of what could be computed rather than formula?

There are two different cases:

1. The row creation is controlled by an action (button) instead of a normal row insertion, so you can set directly the result of computation in a non-formula field.
2. You can set the default value of the column ("VALUE FOR NEW ROWS") (usually for time-based computation).
   In both cases, the value is a… real value therefore not computed every time.
   Pros: avoid unnecessary computations for field that usually don’t change
   Cons: build up actions that perform quality checks for times where they should (manually/automatically triggered).

@nate_hurst

I think you mean same row lookups vs table lookups, but I’m not sure what to do with the table based ones

You are correct.
Maybe you can’t do anything… but having a look if you might reduce the table lookups in less columns Sometimes there are similar table filters that can be widened in a single column and then refined subsequently.

For instance

• Column A
  Table.filter(type="X" && prop1="A" && prop2= "B")
• Column B
  Table.filter(type="X" && prop2= "B")

Could become

• Column Base
  Table.filter(type="X" && prop2= "B")
• Column A
  Column Base.filter(prop1="A")
• Column B
  Column Base

I know this might sound obvious, but sometimes it can be helpful to review it