Some Performance Announcements

Hey everyone!

We’ve been hearing from some users about performance issues in big Coda docs. We’ve designed Coda to be a simple tool to get started but it is also packed with capabilities that let you build very complex docs. In many cases, Coda scales well to the needs of teams of hundreds of people working in the same document. However, as docs keep growing, some of our most loyal users run into performance issues. To that end, we are currently working on a number of fixes to the performance of Coda docs and we will be releasing lots of fixes and sharing details over the next couple of months.

Today, we have some announcements about the first set of performance fixes behind the scenes as well as 2 new tools to help you optimize your docs and make them run even faster. Read on for more details.

1. Performance Improvements in Coda: Over the last few months, we’ve been working hard on an effort to improve the performance of Coda docs. The first set of performance improvements started to go out last week. You may have started to notice significant improvements in scrolling and calculation speed in some docs with big tables. We’re still working on some big improvements and will be releasing many more of them in the coming months and will share more details as we go. Watch this space for more.

2. Learn how to optimize the performance of your Coda doc: As part of this process, we’ve also talked to dozens of users who have performance issues and found that simple changes in your docs can sometimes make a huge difference to performance. Since Coda is such a powerful tool, it lets you use a large number of building blocks but so far there hasn’t been much guidance on which patterns are more optimized for scale versus others. After seeing dozens of slow docs from real users who were kind enough to share them with us, we collected a list of best practices for improving the performance of your Coda doc. We’ve published some help content that help you diagnose the root cause of performance issues in your docs as well as suggest ways to fix them.

Click here to read the collection of help articles on Improving Performance.

3. See what’s calculating in your doc: Coda has a powerful formula language that lets you perform some complex calculations. Behind the scenes, we use advanced database optimization techniques to make your formulas run faster but not all of the formulas we support can be optimized to the same extent. Most of the time, there isn’t a noticeable difference, but as your doc gets bigger, you might start to see things slow down and the “Calculating” indicator show up in your doc for long periods of time. We’ve built a tool that lets you see how long each formula in your doc is taking to calculate so you can find the formulas in your doc that are slowing things down. Most slow docs will have a few formulas that take tens of seconds and sometimes minutes or hours to calculate and slow down the whole doc. Using this tool, you can see which formulas are the bottlenecks and need to be optimized. Then with the help of the help articles above, you can learn what patterns to avoid in your formulas and how to fix them in order to optimize your doc.

In order to use this tool, you can simply click the “Calculating” indicator when it shows up. You can also get to it from the Doc Map, but keep in mind this tool is only for docs that show “Calculating” for long periods of time. For more instructions and tips for fixing other types of docs, please refer to the help articles on Improving Performance.

As we continue to make and release more performance fixes, many of these scenarios will be optimized behind the scenes so you don’t have to do them manually. However, in the meanwhile, we want to help shed some light on the most optimal patterns for big Coda docs.

Jason

42 Likes

Thank you for this! This is going to unlock so much more potential in what you’ve created. Go Coda!!

Update: ok that was amazing. 7 minutes of debugging and the app went from molasses to lightning!

7 Likes

Great announcement! Thoughts on doing future announcements via a Coda doc :thinking:. It would allow users to play with the new functionality while better organizing the content you’re sharing (docs + gifs)

3 Likes

Thanks @Jonah_Kaplan. Have you seen the Product Updates doc?
Love the idea of letting you play with each feature in that doc. Will share with the team!

2 Likes

Exciting news, thank you for listening to our feedback! It’s inevitable that some documents will be slow, but at least having a way to know why and what is slow is really helpful. There’s nothing worse than a blackbox that doesn’t give any hints as to what the issue is.

4 Likes

Totally agree. Our hope is that the analyzer tool is a big step in seeing what’s slowing your doc down and the help content will help you address it.

Moreover, our principle is to make Coda as powerful as possible first, including allowing complex formulas that cannot be optimized. However, we’ll keep doing our best to keep optimizing wherever possible to give you the fastest experience possible as your docs grow.

2 Likes

That’s amazing @Johg_Ananda. Glad you’re already finding this useful and thanks for all your feedback throughout the process.

1 Like

What caused the slowdowns in your doc?

@wisosim Wanted to jump in with quick note here.
We set out to find general guidelines but found that the way to fix every doc is different. That’s why our key insight with performance is “Tools not rules.”
We wanted to give you the tools to find the issues in your actual doc and fix them rather than some overarching rules for what to do.

2 Likes

Some guidance for people looking to use the tool. I had a doc with a table with a set of labor entries, start, stop, units, worker, etc. Each entry then had columns that calculated the ‘units per hour’ and ‘total hours’ worked for each entry.

I have another table that summarized the table with views like ‘worker total hours’, 'units per hour for different projects, each project its own row. Each column was using a long filter against the labor table to pick our the exact entries we wanted. Each formula was the same thing basically, but with a different dot operator at the end to pull out .unitsperhour or .hoursworked.

What insight here was to create one master column that functions as an array and then have all of the other columns in the table reference that array with a dot operator. So whereas I had ‘Units per hour’ column ={long formula}.unitsperhour and ‘Hours worked’ column ={long formula}.unitsperhour instead I now have a column ‘Labor Array’ which brings in everything, and then each column in that table pulls off that array such as Units per Hour column =[labor array].unitsperhour & ‘Hours Worked’ column =[labor array].hoursworked.

The {long formula} still takes a couple minutes to run, but it isn’t factored out to the other 5 columns, providing a massive performance boost.

4 Likes

i’m glad to see such improvements in a tool that is revolutionizing my work and life! thanks team!
btw, those improvements are related to, let’s call it excecution time!

what about the startup time of big docs? especially when on mobile, even with 4G or strong wifi connection, some docs take several seconds(10~15 sec) to open…and that’s frustrating especially when you are on mobile and wanna quickly access some data (only in visualization mode)
it seems as coda loaded huge amount of data at the beginning without any lazy mode to start with minumum data to load the app instantly, neither using some sort of local cache in the device…

i m wondering if you guys are aware of it and already addressing it!

keep rocking!

1 Like

I completely agree with the loading time on mobile. This loading time makes me avoiding the use of the app, as I feel that mobile apps should be used instantly. Take a to do list. Comparing to Todoist, Coda is so slow that it’s hard to empty my mind GTD style.

1 Like

Dear @Johg_Ananda,

Would you mind to create a simple sample doc to show and we can learn from it?

Thank you in advance, :handshake:
//JP

How about adding paging to tables… that might help contain rendering times on computed columns? And is REALLY needed anyway.

Keep up the great work! Thanks!

Hey @Francesco_Pistillo and @tomavatars

We are definitely aware of how slow it can be to load big docs, especially on mobile. Completely agree that it would make a huge difference for cases like quickly accessing or adding data. Unfortunately it’s not an easy problem to solve since at the moment the whole doc needs to be loaded at once but it’s definitely on our list.

Meanwhile we are working on some other improvements to key scenarios first and we expect that will also improve loading time on mobile a little bit. Hopefully we’ll be able to improve doc load speed on mobile soon but can’t commit to a timeline.

Angad

1 Like

Hey @Jean_Pierre_Traets

What Joseph is describing is very similar to the example called “Do not use repeated Filter formulas” in this help article about optimizing slow formulas.

It’s definitely one of the very common patterns we’ve seen in slow docs that can be optimized manually. We’re also working on doing this automatically in the background to make these cases faster even without the manual optimization in the coming months.

Angad

3 Likes

Hey @Richard_Browbek1 we’ve just made pretty substantial improvements to rendering performance of big tables. You might already be able to see your tables & sections scroll smoothly and we have more fixes coming soon. Our hope is that you won’t need to paginate a table in order to be able to scroll through it smoothly or switch sections quickly.

Regarding your request for pagination in general, can you please share a scenario where you would benefit from that feature, regardless of performance? Also, have you tried to use an interactive control to filter your table down to a specific set of rows at a time? (https://help.coda.io/controls/filtering-tables-and-views-based-on-controls)

Angad

Dear Angad,

Thank you soo much to clarify what happens behind the scenes :eyes:

1 Like

Good news about performance. Sometimes it’s a real nag.
What I’ve noticed is, that unused tables can cause slowness.
Here is an example:
The column #Tasks counts the number of tasks in Tasks table that are related to a job in Jobs table.
The point is, that this table is not in View at the moment. So why such an influence on the current process?

24-18-36-39

Hi @Ronen_Mayer, thanks for the question!

We do prioritize calculating values that are in your current view first, but we eventually update all of the calculations in your document be up to date. It is possible that values in your current view depend on values that are out of view, which would bump up the priority of finishing those calculations out of view.

1 Like