Google Sheets Debugging Endless Calculations and Slow Load Time (Chrome Dev Tools) - google-chrome

Working with a Google Sheet that has grown in complexity and size over time and is now calculating endlessly and really slow to open. The sheet has a large amount of data, formulas and import ranges.
I have read best practices on how to speed up sheets link. Does anyone know how to do advanced trouble shooting in Chrome Dev tools to see what formulas are running when and help narrow down what could be causing the problem?
I have used Chrome Dev Tools and the Performance Monitor, but can't see how to locate actual formula [Ex: Sum() or VLOOKUP()] names/location from within the sheet since they are nested under so many layers of functions. (Ex: Function Call > b > P.I2b > p.$Ma > etc)

Related

Suddenly: Service using too much computer time for one day

I have been putting out fires all day. Can't seem to make heads or tails of this error...
Today I started for the first time after months of using the same script. It is triggered when a new record is added to a google sheet.
It seems to work on and off but every few minutes I am getting a failure notice indicating "Service using too much computer time for one day".
Looking through the documentation and the post on Stack, it is clear I am not the first to deal with this issue, but there does not seem to be any concise answer to how to resolve. I looked for some way to reach some type of google assistance but am always directed back to stack overflow to submit my issue for consideration. Understand this could be an issue with my script, but cant seem to find what might be causing this issue. Also confusing the matter is that the script does seem to be firing 90% of the time.
My questions:
How do I check the "computer time" quota?
Should I turn off that script/trigger until 24 hours have passed?
Does anyone know how to get a hold of Google support directly?
I don't know of any way that the total script run time can be seen in a dashboard.
You can see duration times of individual script executions at:
https://script.google.com/home/executions
You could scroll through your executions to look for long durations times. That might indicate an endless loop in your code.
To calculate the total run time of all your running scripts, you'd need to use the Apps Script API.
https://developers.google.com/apps-script/api/how-tos/view-processes
https://developers.google.com/apps-script/api/concepts/processes
I don't have any code to list and compile all the durations.
If anyone does, that would be very interesting.
I don't know if deleting the trigger until the next day would gain you anything. I'm guessing that it shouldn't.
Google does not provide "on demand" support people to answer questions about Apps Script. Even G Suite customers don't get "on demand" support contacts for Apps Script. You can report bugs and request features through the Google Issue Tracker, but that won't get you direct contact with a Google support person. Even if you purchase a support plan, Google doesn't have people who are designated to support Apps Script. If you purchased a support plan, they might try to help you with an Apps Script question, but officially they aren't qualified to help, or obligated to provide Apps Script support. And even if a support person tries to help you with an Apps Script problem, the first thing they'll do is a search of Stack Overflow, and give you links to SO posts.
So, it's extremely unlikely that you're going to be able to talk with someone directly at Google.
The best thing to do is to review your code for performance issues. Avoid reading the writing data often. The ideal situation is to get all the data that you need just once, process it, and write it back once. Cache data if you can. Avoid lots of calls to Properties Service. Find what part of your code is taking the longest time, and try to improve it.

Evaluate Google Sheet offline programmatically

What's the best way to evaluate a Google Sheet without using the API? By evaluate I mean, change some cells and recompute the dependent cells.
You can use Google Sheets offline, so they have to be stored somewhere and the evaluation code also needs to run offline. How can I control this functionality from JS/Python?
I need to run thousands of computations as quickly as possible and the API would be too slow for this / I would get rate limited.
You can use Google Sheets offline, so they have to be stored somewhere and the evaluation code also needs to run offline. How can I control this functionality from JS/Python?
For offline support the data must be stored by the browser.
You can use the browser's Developer console to inspect the data-stores supported by that browser (ie. IndexedDB, Local Storage, Web SQL, etc.). From what I can see from Google Chrome (go to your developer console and select the Application tab), you can find some google docs data mirrored in IndexedDB databases.
Unfortunately, I don't believe you can interact with that data in any meaningful way outside of the dev console. Plus some of that data appears to be encrypted.
If your goal is to use Google Sheets as a analytics platform to perform heavy computation then you're in for a lot of disappointment. As you're no doubt discovering Google Sheets are bound by a number of limitations and its not meant to be used in that capacity. You probably need something more robust and that means moving to more traditional database solutions, but they wont' be free.
You should consider using normal formulas, this documentation will show you the basics on how to use them for regular data management in the Sheet.
After that, you should see this list of functions to know what tools you have available to create the functionality that you want.
Lastly, you should see this tutorial on creating your own formulas, it can be helpful to expand what the normal functions can do and have a more tailored solution to your needs.

Force mobile implementation for Google Sheets

I've noticed that a tab on a particular Google Sheet we've developed 'runs' a lot faster (about 70-80 times faster) on a mobile than on a desktop - ie it calculates and returns its results faster. The one tab in particular that uses a query to filter a master database. I surmise that this is because there's a very reduced 'view' window on a mobile and Google Apps cleverly off loads the heavy lifting to its servers when it sees a mobile opening the sheet.
My question is, and this is speculation, can I use a script to force a particular Google Sheet to always report to the Google Servers that it's running on a mobile?

Google Apps Script close spreadsheets programmatically

Google lists a maximum of 50 concurrent users allowed edit permission at once in a shared spreadsheet
https://support.google.com/docs/answer/2494827?hl=en&rd=1
I've got a Google Spreadsheet that will have a large number of potential editors at any moment and am concerned about idle users filling up the 50 cap and blocking edits from fresh logons. There's a lot of interaction with the data that discourages me from using Forms submissions, and there would be a large bound script to the document.
Is there an idle timeout function that can be called through the spreadsheet's bound script that will close the document or set an idle user to view only status? This is in a Google Apps for Business domain.
This is a question that was asked very often 6 years ago on the old Google product forum when I began to work with Google spreadsheets.
Strangely the question disappeared after a while and never came back (until today !)
There are two main reasons for this question to disappear :
Since Google spreadsheets are a representation of a documents hosted on a distant server, we can not interact with what happens in another user browser from a script that runs on this distant server
I suppose this is rarely an issue and that in most case it was mainly a theoretical question that vanished in real use. (but that is really a supposition, I admit...)
As far as I know there is no practical solution to avoid that situation.

Google Apps Script gadgets - what's loading when?

I've seen inconsistent load times for Google Apps Script gadgets on my Google Sites. There seem to be two visible phases to the gadget loading process - a "blank" period, and a period with a "loading" animation. Can anyone explain the relationship between these two phases? I suspect but have no way of knowing that my code does not begin to execute until the loading animation is complete. Is this true?
My scripts seem to perform relatively consistently once they reach the loading animation. I have reviewed the available documentation on optimizing performance for Google Apps Scripts, and I have been able to get reasonable load times for my requirements, but the gadget sometimes spends a long time - over 60 seconds - with no content prior to the loading animation appearing.
I have one page with three Google Apps Script gadgets on them, with three very different performance profiles. I am loading data from a spreadsheet in two of them, but I need to iterate through Google Contacts in another which takes quite a bit longer. It appears to me that once one of these scripts hits the "loading" animation, they all begin executing fairly quickly, but nothing I do as a developer influences the time prior to the loading animation.
Web browsers are single threaded when doing server calls in Javascript (or GAS) so it needs to complete all of your function calls to the server before it can return the values from the server and render your page. A workaround would be to create a simple button on the page to start your GAS processes then have a loading screen come up via a clienthandler when the button is pressed. The load screen will be visible as the processes are going on in the background and when you finally finish your processes, you can set the load screen (panel) visibility to false.
Not the most elegant solution, but your initial page will render quickly then you an set a panel (with an animated gif loading graphic if you prefer) to tell the user the page is loading.
Hope this helps!
Interesting question. But I'm afraid there's really nothing else that we can do.
Well, besides complaining with Google :)
I guess you should open an "Enhancement request" on the issue tracker.