Are pack formulas built in the Packs Studio significantly slower than simply replicating the same formula in our docs with native Coda formulas (when possible)?
Heres my use case and specifics:
I just built my first pack - Its a Hex code → RGB converter. Essentially just: Turns this → #628dbd Into this → (98, 141, 189)
I also built this functionality natively in my Coda doc (using Coda formulas)
Issue:
When I ran my Pack formula on a table of 950 rows, it took 4 min and 30 seconds to calculate. Thats a long long time.
When I used Coda native formulas (about 3 columns worth), it took mere seconds to calculate
This leads me to believe one of the following:
The javascript code I wrote behind the pack simply stinks, and if it was more efficient, my pack would be too.
Pack formulas built in pack studio are just way slow right now due to it being in beta
Pack formulas are, and always will be just inherently slower than writing a Coda native solution, and coda native solutions should be preferred when possible
Can anyone enlighten me on what is going on? 4th option I’m not aware of?
Hi @Scott_Collier-Weir - That’s a great observation, and nice to see data to back it up! This difference in speed is due to how these different types of formulas are run. Pack formulas are run on a server, with each formula call being run on a separate server. There is an overhead for each call, sending the data over the network and getting the server warmed up, which is small in absolute terms but as you have found can add up. Coda native formulas are instead run in your browser, which has no such overhead and allows for a lot of calls to be processed in parallel.
I think in many cases the convenience and additional capabilities (pulling in external data) of Pack formulas is worth the tradeoff, but there are times when the speed matters and native Coda formulas will be the better choice for now. We’ve already started having some discussions about ways we can improve the speed of Pack formulas, but I wouldn’t expect any significant changes in the near term.
Sorry to bring this thread back up - But i’ve been thinking about packs and speed a good bit these last few days.
During the block-party where the Packs-studio was announced, it was shared with the example use-case of a small conversion-pack made for a recipe and the clear benefit was that it would save users time by streamlining formulas written in Coda that were often lengthy creating a custom pack/formula for these use cases.
I’ve been building packs like this - but now find myself preferring to just writing the longer more cumbersome formulas in Coda on the front end, but saving myself even more time in the long run as my docs are just faster.
This kind of seems to defeat the purpose of building custom packs. Specifically custom packs that don’t pull in external data via an API.
Would it be possible to choose when making a pack (that doesn’t pull in data via API) to run your pack in in ones your browser rather than “sending data over the network?”
Some things are just easier to calculate in JS than in Coda. For example, running some while-looped calculations, e.g. calculating task end dates based on start dates and people’s complexly set up availabilities would happen much faster in JS than within an iterator table or a fickle forced-recalc formula
Also it may serve those teams where most of the Coda users are not skilled enough to come up with complicated formulas and algorithms, yet they want to not just use the doc they’re given but extend it with calculations that matter to them. The team could employ a JS coder to prepare some pack functions and only that — faster for the coder who doesn’t have to set up everything on the Coda side, and the not-so-tech-savvy team are happy to just go and use those formulas.
Totally makes sense - but I’m not arguing against the functionality of packs or the different use-cases/advantages you described.
Merely saying it would be nice to have the option to run these super helpful packs/formulas in our browser for speed depending on the pack.
Thinking that if a company or team builds out these JS formulas, the team won’t in the long run buy into Coda due to the speed of these formulas while using.
It’s a great point @Scott_Collier-Weir, and I wouldn’t want to see an initial bad experience with these sorts of formulas turn people off from Packs. I’ll raise this with the team again, at least to see how we can set expectations so that folks aren’t disappointed with the current limitations of how Packs are run.
Ah, well, yeah, I agree that it would be nice to be able to run some subset of JS on the client side. Only the language APIs, no HTTP, no window manipulation and so on. Perhaps even not directly but through a sandboxed interpreter.
I think it was initially planned to have both client-side and server-side packs, but I guess they scrapped it, at least for v1, for security purposes.