Praca nadGoogle Sites strona, która pobiera dane z arkusza kalkulacyjnego i dynamicznie buduje kilka wykresów, wspomniałem, że skrypt Google Apps działa dość wolno. Profilowałem kod i optymalizowałem go, używającPamięć podręczna Usługa, tam gdzie jest to możliwe. Po optymalizacji kod wykresu zajmuje ok. 3 sekundy (2759 ms to jeden z najszybszych czasów, jaki kiedykolwiek widziałem), aby narysować 11 wykresów o 127 rzędach. I tym razem dotyczy to sytuacji, gdy wszystkie dane są umieszczane w pamięci podręcznej. Pierwszy czas wykonania, który pobiera dane z arkusza kalkulacyjnego i umieszcza je w pamięci podręcznej, wynosi około 10 sekund. Profilowany kod wymagał wystarczającego czasu (dziesiątki milisekund) w prostych miejscach. Aby zmierzyć wydajność GAS, napisałem bardzo prostą procedurę i wykonałem ją w środowisku GAS, jako wdrożona aplikacja internetowa oraz wPlac zabaw Caja. Przesłałem równieżkwestia do śledzenia problemów z GAS.

Eric Koleda rozsądniewzmiankowany, że nie jest poprawne porównywanie kodu serwera z kodem uruchomionym na kliencie. Przepisałem kod testu porównawczego i oto wyniki. Szczegóły i wyjaśnienia są następujące.

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 - w silniku GAS uruchomiono wiersz zawierający czasy wykonania różnych funkcji. Wszystkie czasy są w milisekundach. Czas realizacji GAS dryfuje w dość szerokich granicach. W tabeli są najbardziej szybkie czasy, w których miałem 5-10 egzekucji. NajgorszeComplete czas, który widziałem, wynosił 1194 ms. Kod źródłowy totutaj. Wyniki sątutaj.rhino-1.6.5 ispidermonkey-1.7 - wiersze zawierają czasy wykonania tych samych funkcji coGAS ale wykonywane na odpowiednich silnikach Javascript za pomocąideone.com. Kod i czasy dla tych silników sątutaj itutaj.

Kod testu porównawczego zawiera kilka funkcji.

List To Map [listToMap] - funkcja, która konwertuje listę obiektów na mapę z kluczem złożonym. Jest pobierany ze skryptu witryny i zajmuje ok. 9,2% (256 z 2759 ms) kodu wykresu.Adjust [adjustData_] - funkcja, która konwertuje wszystkie kolumny dat w macierzy na tekst we wstępnie zdefiniowanym formacie, transponuje go i konwertuje wiersze z[[[a], [1]], [[b], [2]]] formularz do[[a, 1], [b, 2]] jeden. Jest również pobierany ze skryptu i zużywa około. 30,7% (857 z 2759 ms).Sort - standardowyArray.sort Funkcja ta jest dołączona do testu, aby sprawdzić, jak szybko działa standard pracy.Quick Sort [quick_sort] - wzięto szybką funkcję sortowaniatutaj. Jest dodawany do testu porównawczego w celu porównania zArray.sort czas wykonania funkcji.Complete [test] - funkcja, która obejmuje wywołania funkcji, przygotowanie danych testowych i funkcje wymienione powyżej. Tym razem nie jest podsumowanie czasów w stanie surowym.

Wniosek: Czas realizacji funkcji GAS dryfuje. GazComplete funkcja działa1.6 razy wolniejszy niż najwolniejszy konkurent. Standard GASArray.sort funkcja jest4 razy wolniejszy niż najwolniejszy z dwóch innych silników. UsługiList To Map iAdjust w skrócie3 razy wolniejszy (334 ms vs 111 ms) niż najwolniejszy konkurent. Funkcje pobierają 39,2% (1113 z 2759 ms) funkcji tworzenia wykresów. Nie spodziewałem się, że te funkcje działają tak wolno. Można je zoptymalizować, na przykład za pomocą pamięci podręcznej. Załóżmy, że po optymalizacji czas wykonywania tych funkcji będzie wynosił 0 ms. W tym przypadku wykonanie funkcji wykresowania wynosi 1646 ms.

Życzenia: Jeśli zespół GAS mógłby zoptymalizować swój silnik do prędkości najwolniejszego zawodnika, można oczekiwać, że czas wykonania skróci się do 1 sekundy lub mniej. Świetnie byłoby również zoptymalizować czas pobierania danych z arkusza kalkulacyjnego. Rozumiem, że arkusze kalkulacyjne nie są zaprojektowane do obsługi dużej ilości danych, ale w każdym razie zwiększy to ogólną wydajność.