Improvements to Calculation Performance

We meant it when we said we’re committed to improvements for doc performance! We’ll continue to share updates on our progress in this space as they roll out so that you, our valued makers, know where to expect improvements.

In the past few weeks we’ve made over a dozen improvements focused on doc calculations. Among these updates:

  • Instantly expand rows via activate action. We have updated our infrastructure to allow the Activate(thisRow) action to run without getting blocked behind calculations. Why does this matter? When you interact with a button, every action in that button waits for all outstanding calculations to complete. This ensures that the actions are performed on a stable state of the document. However, sometimes this also means that button actions in documents running a lot of calculations can take a long time to completeーeven if they aren’t reliant on the calculations. We recognize that this logic is overkill for buttons that don’t depend on calculations, so we added infrastructure to detect actions that fall in this category, and no longer delay their actions due to calculations. Activate(thisRow) is one such action. So now, if you have a button that is supposed to open a row, it will do so instantly even if the doc is running other, more complex calculations. Overtime we will continue to add more actions to this list.
  • Instantly add new comments. As you all know, formulas are a core building block in Coda. We even rely on them in a lot of our own features, and one such feature is comments. In general this works really well; however, adding a new comment to a row could result in latency if the document is running a lot of calculations. When adding a new comment, we found that we could work around the calculations to reduce this latency down to being almost instant. So, similar to the change above, we added an optimization where we detect this case and skip the calculations. This now means that adding a comment on a row no longer lags just because other calculations running in the doc.
  • Overall code optimizations. We also generally updated a lot of internal code to optimize for speed. As engineers, one of the key things we all strive for is making sure that the code we build is simple to follow, easy to read, and easy to maintain. To help with these goals, we have been using several well known libraries (for example lodash) through out our code base. This can be double edged sword sometimes, and some of the methods in these libraries can add a lot of performance overhead which is not desirable in hot code paths. We have been removing all such methods in hot code paths, which should result in an overall improvement in your experiences throughout the product.
  • Improved typing experience in table cells . Another area where the product felt slow was when typing text content in a cell in any table with a lot of rows where the cell values are all mostly unique. In these cases, we would try to generate a suggestion list which used to take a long time, and this resulted in a slower typing experience. Now we have added infrastructure where we defer the generation of suggestions to be asynchronous. This now enables a much faster typing experience inside table cells.
  • Improved form load time . When loading a form, it could take a significant amount of time to fill-in containers of data used in traditional docs that are not used by forms. This was due to the fact that forms and docs share much of their underlying infrastructure. We’ve identified places where Coda was unnecessarily waiting for data that is required for docs and not for forms, and now forms should load much more quickly as a result.

We recognize these improvements might not impact all docs, but we did our best to address some of the most commonly reported issues, as well as issues that tend to have the most impact as docs grow in size and scope. As we continue to make docs perform better for you, we’d love to hear more from you about where you’d like us to do better. If you have a performance issue with your docs, please let us know via this form.

We look forward to sharing more improvements with you soon!


Amazing stuff, thank you so much! Anything we need to do to benefit from the updates? Just hit refresh?


Yes, just refreshing the docs should give you all the updates.


Oh awesome! I just noticed half an hour ago how loading the @-ref suggestions in a formula editor in a doc with 5000+ rows became nearly instant. Previously Coda used to take a few seconds per keystroke to give you that list.


Can you elaborate more on the Activate() scenario, @Himanshu?

What if I run a sequence of actions, e.g. ModifyRows(), AddRow(), something, something, and then Activate(), and expect the popup to only appear when all the behind-the-scenes stuff is done and the row is ready to open?

Also, a separate request but since we touched Activate(), can we please have the option to open an expand row layout for a view and not the base table? Because at the moment we have to resort to this workaround with manually constructing modal URLs: Mega trick: Different "Expand row" layouts for the same row


In the case you described, Activate will still wait for all the calculations to complete before displaying the row.

Also, we hear you on the ability to point to a row layout as part of activate. This change is a little bit more involved because in order to do this we need to create a mechanism for referencing the layouts which we don’t support as yet. This is something we have heard previously as well and want to do. We don’t have a concrete timeline on this as yet, but let me see what we can do here.


Keep up the good work, team. Amazing release comms!

1 Like