Question

Working on a Google Sites site, which takes data from a spreadsheet and builds several charts dynamically, I mentioned that Google Apps Script works quite slow. I profiled the code and optimized it, by using the Cache Service, where it is possible. After optimization the charting code takes approx. 3 secs (2759 ms is one of the fastest times, which I have ever seen) to draw 11 charts having 127 rows. And this time is for the case when all data are placed to the cache. The 1st execution time, which fetches data from the spreadsheet and places them to the cache, is around of 10 sec. The profiled code required sufficient time (tens of milliseconds) in simple places. To measure the GAS performance, I wrote a very simple procedure and executed it in the GAS environment, as deployed web application, and in the Caja Playground. Also I submitted an issue to the GAS issue tracker.

Eric Koleda reasonably mentioned, that it is not correct to compare a server code with a code running on a client. I rewrote the benchmark code and here are the results. The details and explanations are the following.

Engine          |List To Map|Adjust|Quick Sort|Sort|Complete|
GAS             |        138|   196|       155|  38|     570|
rhino-1.6.5     |         67|    44|        31|   9|     346|
spidermonkey-1.7|         40|    36|        11|   5|     104|

• GAS – a row containing the execution times of different functions ran on the GAS engine. All the times are in milliseconds. The GAS execution time drifts in quite wide limits. In the table are the most fast times which I had across 5-10 executions. The worst Complete time, which I have seen, was 1194 ms. The source code is here. The results are here.
• rhino-1.6.5 and spidermonkey-1.7 – rows contain the execution times of the same functions as GAS but executed on correspondent Javascript engines using ideone.com. The code and times for these engines are here and here.

The benchmark code contains a few functions.

• List To Map [listToMap] – a function which converts a list of objects to a map having a compound key. It is taken from the site script and takes approx. 9.2% (256 of 2759 ms) of the charting code.
• Adjust [adjustData_] – a function which converts all date columns in a matrix to a text in a predefined format, transposes it and converts rows from the [[[a], [1]], [[b], [2]]] form to the [[a, 1], [b, 2]] one. It is also taken from the script and consumes approx. 30.7% (857 of 2759 ms).
• Sort – a standard Array.sort function, it is included to the test to see how fast work standard functions.
• Quick Sort [quick_sort] – a quick sort function taken here. It is added to the benchmark to compare with the Array.sort function execution time.
• Complete [test] – a function which includes calls of functions, preparing test data, and the functions mentioned above. This time is not summary of times in a raw.

Conclusion: The GAS functions execution time drifts. The GAS Complete function works 1.6 times slower than the slowest competitor. The GAS standard Array.sort function is 4 times slower than the slowest of two other engines. The service List To Map and Adjust in summary are 3 times slower (334 ms vs 111 ms) than slowest competitor. The functions take 39.2% (1113 of 2759 ms) of the charting function. I did not expect that these functions work so slow. It is possible to optimize them, for instance, using the cache. Let’s assume that after optimization, these functions execution time will be 0 ms. In this case the charting function execution is 1646 ms.

Wishes: If GAS Team could optimize their engine to the speed of the slowest competitor, it is possible to expect that the execution time reduces till 1 sec or less. Also it would be great to optimize time to fetch data from a spreadsheet. I understand that the spreadsheets are not designed to handle a big amount of data, but in any case, it will increase overall performance.

Answer 1

I’ve been able to replicate this performance, and I’ll post updates on the issue as I receive them.