V8 vs. Rhino engine

[Ed Bacher]

I know there are some older discussions of this, but I just ran into an issue with the V8 engine. I updated my add-on, Docs to Markdown, and I thought I would use the latest JavaScript engine (and some of the nice language features). But when I release, I noticed a lot of errors (ScriptError: Exceeded maximum execution time). So I rolled back to a stable version and started doing some experiments.

I measured the elapsed time to convert a document to Markdown or HTML (this is not the execution time on the server, which is limited to 30 seconds, I believe). I started with my basic test document, which is 27 pages long, and kept doubling the size. At every size, the V8 engine was significantly slower (3-5 times slower than the Rhino engine). I got to 64x (833 pages) before the V8 engine gave me the (ScriptError: Exceeded maximum execution time) error. At 208 pages,the Rhino engine took just over 30 seconds, while the V8 engine took more than 130 seconds.

For now, I'm going to stick with the deprecated Rhino engine for my own and other users' satisfaction. I hope Google can improve the performance of the V8 engine.

Here's a graph:

[Ed Bacher]

Sorry -- graph is nearly unreadable with default font sizes. This should be better:

[DimuDesigns]

I'm surprised that the Rhino runtime is faster given your use case. Does your add-on rely heavily on the Utilities service? I've found that its methods run considerably slow compared to pure Javascript implementations imported from NPM under the V8 runtime.

Also, Google Docs now natively supports downloads/exports to markdown.

[Ed Bacher]

Thanks, DimuDesigns -- my add-on does not use the Utilites service at all (minimal use of services all around).

Googe Docs does support export to Markdown now, but there are still some deficiences (complex tables are a notable one).

Ed

[Ed Robinson]

Maybe some operations are faster in Rhino and some in V8?

Benchmarking File operations, I found Rhino adds an average of 22% to 63% more time to complete an operation than V8

Methodology

I needed to find a reliable and fast mechanism to detect the modified date of a Drive file, and wrote a script that benchmarks file operations; comparing the speed/accuracy of DriveV2 vs DriveV3, Service vs REST API, and DriveActivity, Revisions API.

I switched it to Rhino - 100 iterations of "get the last modified data of a file", and 20 iterations of "copy a file" (long running operation). 

Rhino is consistently slower when using IAM authenticated file APIs.

How to read this data: 

Using DriveApp Workspace Service, an operation like:

 modifiedTime = new Date(DriveApp.getFileById(inFileId).getLastUpdated())

takes 0.13 seconds to read the file modified date in V8, 0.24 seconds in Rhino (85% more time), when averaged over 100 iterations

Also another fun fact: When a file has been recently modified, the Revisions API is the only way to get the accurate modified time.

Ed

[Ed Bacher]

Thanks, Ed -- I'll have to add some profiling code to my add-on to see what's taking so much time in V8. (And then do some benchmarking of Rhino vs. V8 for operations that seem problematic.) I'm not doing much with any service, just reading text and structure from Google Docs.

Ed

Ed Bacher | ed.b...@gmail.com 

--
You received this message because you are subscribed to a topic in the Google Groups "Google Apps Script Community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-apps-script-community/0H2INIewQ8I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-apps-script-community/90476222-a29a-40ae-92ec-9fe20065adebn%40googlegroups.com.