GAS的性能比其他服务器端的JavaScript慢 [英] GAS performance slower than other server-side JavaScript

问题描述

在 Google网站网站上工作，该网站从电子表格中获取数据并动态构建多个图表，我提到Google Apps脚本的运行速度很慢。我通过使用缓存服务对代码进行了剖析并对其进行了优化。优化后的图表代码大约需要。 3秒（2759毫秒是我见过的最快的时间之一）绘制有127行的11个图表。这一次是所有数据都放到缓存中的情况。从电子表格中提取数据并将它们放入缓存的第一个执行时间约为10秒。分析代码在简单的地方需要足够的时间（数十毫秒）。为了测量GAS性能，我编写了一个非常简单的过程，并在GAS环境中执行它，作为已部署的Web应用程序，并在 Caja游乐场。此外，我还提交了问题 GAS问题跟踪器。

Eric Koleda 合理地< a href =http://code.google.com/p/google-apps-script-issues/issues/detail?id=1678#c1 =nofollow noreferrer>提及，它是不正确的是将服务器代码与运行在客户端上的代码进行比较。我重写了基准代码，这里是结果。详细信息和解释如下。

 
引擎|列表映射|调整|快速排序|排序|完成| 
 GAS | 138 | 196 | 155 | 38 | 570 | 
 rhino-1.6.5 | 67 | 44 | 31 | 9 | 346 | 
 spidermonkey-1.7 | 40 | 36 | 11 | 5 | 104 | 
 

• GAS - 包含执行时间的行在GAS引擎上运行不同的功能。所有的时间都是毫秒。 GAS执行时间在相当宽的范围内漂移。在表中是我在5-10次执行中遇到的最快速的时间。我所看到的最差完成时间为1194毫秒。源代码为此处。结果是此处。


• rhino-1.6.5 和 spidermonkey-1.7 - 行包含与<$相同的函数的执行时间c $ c> GAS ，但是使用 ideone.com 在对应的Javascript引擎上执行。这些引擎的代码和时间为此处和 here here。

基准代码包含一些函数。 b
$ b

• List To Map [listToMap] - 将对象列表转换为具有复合键。它来自网站脚本，大约需要。 9.2％（2759 ms中的256）的图表代码。
  
• 调整[adjustData _] - 将所有日期列转换为将矩阵转换为预定义格式的文本，将其转换并转换来自 [[[a]，[1]]，[[b]，[2]]] 表单到 [[a，1]，[b，2]] 一个。它也从脚本中获取并消耗约。 30.7％（2759 ms的857）。
  
• Sort - 标准 Array.sort 函数，它包含在测试中以查看工作标准函数的速度。
  
• Quick Sort [quick_sort] - a快速排序功能此处。它被添加到基准中以与 Array.sort 函数执行时间进行比较。
  
• 完成[test ] - 一个包含函数调用，准备测试数据和上述功能的函数。这段时间不是对原始时间的总结。

结论： GAS函数的执行时间有偏差。 GAS 完成函数的工作速度比最慢的竞争对手慢1.6个百分点。 GAS标准 Array.sort 函数比其他两个最慢的引擎慢4倍。总结中的服务 List To Map 和 Adjust 慢了3倍（334 ms vs 111毫秒）比最慢的竞争对手。这些功能占图表功能的39.2％（2759毫秒的1113）。我没有想到这些功能运行得如此缓慢。可以优化它们，例如使用缓存。我们假设在优化之后，这些函数的执行时间将为0毫秒。在这种情况下，制图功能执行时间为1646毫秒。

祝愿：如果GAS Team可以根据最慢竞争对手的速度优化引擎，有可能预计执行时间减少到1秒或更少。此外，优化从电子表格中提取数据的时间也会很不错。据我所知，电子表格并非设计用于处理大量数据，但无论如何，它都会提高整体性能。 解决方案

p>我已经能够复制这个表现，并且我会在收到问题时发布更新。

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.

解决方案

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

这篇关于GAS的性能比其他服务器端的JavaScript慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！