Some Performance Announcements

[Paul_Danyliuk]

My 5c regarding performance.

For non-trivial use cases, no wonder it would take non-trivial skills to make them right. For docs that are more like apps, having software engineering skills and thinking would be very helpful.

E.g. just a recent example of optimizing an “endlessly recalculating” doc:

PSA: Replace Now() with a lower-resolution real time clock for heavy formulas

UPD: For anyone finding this trick in 2023 and beyond — don’t use it anymore! Use Now() with precision, e.g. Now("minute") or Now("hour"). For the record, there are two hidden functions, NowInMinutes() and NowInHours() but the officially supported one is Now() with an argument. Sometimes you need to calculate things based on current time (e.g. conditionally format tasks that are due, or show different text values for when the time is in the past or in the future). And sometimes those calcula…

And just a few days ago I optimized a very complex calculator I built for another client: I managed to reduce time required to add a set of rows from ~30 minutes down to ~3 minutes.

In both cases I just analyzed heavy formulas / unnecessary recalculations, and thought of how to bypass those. E.g., in the 30 min → 3 min case I streamlined the dependency flow (i.e. so that table B depends on table A, but nothing from table A depends on table B) and replaced a fair share of “live formulas” with inputs that could be populated just once with a button. FYI this was a table where rows were dependent on other rows from the same table (think recreating Excel cells where each cell is a Coda row), so adding a row would’ve triggered recalculations over the whole table.

This reply would’ve been a shameless plug because I’m doing Coda consulting for a living and optimizing perf is just one of the things that puts food on my table. But I’m insanely overworked already, so not a shameless plug this time

[Paul_Danyliuk]

I’ll cross-post some recent learnings here too:

This doc is too big to sync

Here are a few very short facts. I’ll expand on these in my blog when I have more time. The doc size limit is 125 megabytes. This is 0.json (schema file) and 1.json (data file) size combined in their uncompressed form: [image] When the doc goes over this limit it becomes “too big” and you won’t be able to access it through API / Cross-doc, and automations will most likely not run either. You’ll still be able to open it in your browser — it just won’t open on Coda servers for automation/API…

[Colin_Nickerson]

I agree with Paul that having software engineering skills helps … but even with those we hit a performance limit in a few months of Coda use.

We are using it for tasking and live documentation. We have around 2000 rows and its just getting to be too slow for actual use. We have about 600 rows for tasks and the rest come from cool features we added like scrum updates, asset pages, reference tables.

We really embraced coda and made very good workflows and as a result our project goals became clearer … but I am heading “Coda is so slow” comments across our team on a daily basis.

It is just too bad that I spend time every week looking to see if any performance improvements have been made …

[BenLee]

Hi @Colin_Nickerson,

For the numbers you posted, that’s kind of unexpected for you to hit slowness. When I see this happen, there are a few things that I check on.

• Previous row formulas - These cause the entire table to recalculate when anything happens that might change the columns referenced. This is a very inefficient schema and should be avoided if possible.
• Many-to-Many lookups - If your tables lookup to each other in a many to many fashion where you try to have all data visible in all tables, this can cause lots of calculation dependencies when any changes are made in any table. Add people to a project or projects to people, but don’t try to do both in full fidelity.
• Lots of lookup results per cell - Having a lookup column that has 100’s of lookup values in each row can cause the same issues with calculation dependencies and also starts to be an issue with column size.

I’d be curious to check out the doc if you’re open to sharing it. Feel free to write into Coda Support and and mention or link to this post and ask them to route it to me if you’re up for it.

And we do have a consistent and major focus on performance that has been on going for several months. Some items are foundational and take a long time to get in place, while others are easier and quicker fixes. Our work over the last several months has set up a great groundwork for us to start implementing these tweaks faster, so more performance updates are on the way!

[Colin_Nickerson]

Thanks for the info Ben. We do have many-to-many relationships, not really sure how to get around that in some instances.

Unfortunately I don’t feel comfortable sharing out the doc as it has stuff that would normally be under a NDA, but I can try to put something together that illustrates how we are using coda as I can understand why that would be useful to the development team.

Also, thanks for the information on the performance work. I really like using Coda and would like to keep building around it if possible

[Billy_Armstrong]

I am very pleased with the way Coda cares and delves into their customers. The forum itself has already been made quite qualitatively and pleasantly. This played a decisive role in my decision to buy a subscription. And now, when I see that developers take into account the opinions of users and do their best to optimize the software, I understand that I am with Coda forever!