Short answers; will expand sometime later in a blog post
Expensive formulas:
-
Operations that become exponentially slower as the data set grows. Example: in Classes table, a column that looks up all previous classes by the same student. Every time a class is added, it recalculates all rows, and every time it’s comparing each row with every other row of the data set that grows (hence N^2 operations)
-
Along with the previous one: operations that unnecessarily recalculate data that is known to not change. Same example as above: looking up previous classes. When you’re adding new rows which are classes in the future, you know that this new row will not affect the calculation result of the past 1000 of classes, yet Coda would recalculate the whole column anyway. Solution in this case: to not use the formula column but calculate once on demand instead (e.g. with a button, and write the filter result in an editable cell)
-
Operations that result in multiple recalculation cycles. These happen when you have circular dependencies in your data. Example: you have tables Posts and Tags where each row on Tags is linked to a Post, and the table Posts has a lookup column that looks up all tags for this post. You have a button that adds 10 tags to a post, but each time it looks up into
yourPost.Tagsto see if it hasn’t been added already. Normally Coda is capable of performing many AddRows in one quick burst, but in this case there’ll be a delay between each AddRow because Coda will add a row, then recalculate Post.Tags column, only then add another row, then again recalculate Post.Tags column etc. Solution: rewrite the formula to not depend on Post.Tags on each iteration, but e.g. pre-filter the list of tags to add. -
Everything else laid out in that optimizing help article, like avoiding using filters within filters.
Expensive schema:
- Elements that Coda stores inefficiently, e.g. Buttons and conditional formatting, contribute to the doc size a lot. More: This doc is too big to sync
Workaround for buttons in large tables (500+ rows): instead of adding those in such tables directly, make a small helper table that would host that button and perform the desired operation on another table. On the big table you can have a checkbox to select on which rows to perform that operation. Example: we have a huge (2000+ rows and counting) Classes table that is meant to scale for as long as possible, but for each added class we need to send out an email notification and calendar invite. Instead of having 2000+ buttons that are stored individually on the schema, I rewrote the logic so that an external button is sending that out for recently added rows. - Unnecessarily storing plain text as formatted text. More: Here's a doc size riddle for the community
- Cross-doc also takes more space than tables within the same doc. So if you’re thinking of splitting the doc into smaller docs but still importing all the data in, that’ll only do harm in terms of doc size.
The holy grail of tips is gonna be here eventually: codatricks.com, but that’s after I’ll have beaten my depression current apathetic mood towards anything.
this sounds like a lookup formula for a lookup column in the same table, yes?
