#1 2021-03-23 19:25:11

mpv
Member
From: Ukraine
Registered: 2012-03-24
Posts: 1,330
Website

QuickJS performance

There is already a QuickJS benchmark but it's too complex. I create a simple test (circles, if's, arrays, strings)

function f(n) {
  let r = 1
  for (let i = 2; i <= n; i++) r *= i
  return r
  //return (n != 1) ? n * f(n - 1) : 1
}
let v = 0
let s = ''
let arr = []
const L = 1000
for (let l = 0; l < L; l++) {
  v +=10; arr = []
  for (let i = 0; i < 10000; i++) {
    arr.push(i % 10 == 0 ? f(5) : l)
    if (i % 100 === 0) {
      s += i.toString(16) // on V8/SM actually build a rope, not a huge string
    }
  }
  arr.forEach(k => { v += k })
  let s2 = s.replace(/a/g, 'x') // hope this convert rope to string
  v += s2.length
  v += arr.length
}
console.log(v)

And a results:

$time qjs f.js 
real	0m12.201s

$time ub f.js #SyNode
real	0m1.750s

$time node f.js
real	0m0.695s

SpiderMonkey

Offline

#2 2021-03-23 19:32:26

mpv
Member
From: Ukraine
Registered: 2012-03-24
Posts: 1,330
Website

Re: QuickJS performance

IMHO not bad for QuickJS. I also analyze a memory consumption tor tests above ( excluding a size of empty runtime) and a results are:

QuickJS -  7Mb
NodeJS - 45Mb
SyNode - 53Mb

So here (thanks to reference-counting GC model) QuickJS is win

Last edited by mpv (2021-03-23 19:32:47)

Offline

#3 2021-03-23 20:47:14

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 13,368
Website

Re: QuickJS performance

Yes, I have seen that QuickJS memory consumption is very low.
It also means that there is less stopping GC involved... a more deterministic model is better for server side.

About performance, for simple workflow, and already compiled content, it may be good enough for most use-cases, even on server side.
If you JS is only processing strings, and we can call native code for the actual process (DB, JSON), we may have good performance.

Offline

#4 2021-03-24 11:25:12

edwinsn
Member
Registered: 2010-07-02
Posts: 1,196

Re: QuickJS performance

It seems that https://github.com/tondrej/chakracore-delphi is not in the benchmark list? wink


Delphi XE4 Pro on Windows 7 64bit.
Lazarus trunk built with fpcupdelux on Windows with cross-compile for Linux 64bit.

Offline

#5 2021-03-24 15:51:30

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 13,368
Website

Re: QuickJS performance

Note that the benchmark code is somewhat irrelevant, since "s += ..." is definitively not the way to concatenate strings.
My guess is that using join() would make the difference with QuickJS less relevant...
Only f() can be aggressively JITted, and I suspect we don't write such code often in business workflows - especially f(5) which returns a constant so could be optimized as a constant by a good tracing JIT, if it can guess it is a pure function.
I would rather see a real benchmark using real world logic from a DB or JSON.

Offline

#6 2021-03-24 16:34:02

mpv
Member
From: Ukraine
Registered: 2012-03-24
Posts: 1,330
Website

Re: QuickJS performance

I can't  compile ChakraCore, but works on it.

@ab - s += '...'  do not concatenate a string, but actually build a rope structure, at last in SpiderMonkey and V8. 
I know it very well, because catch OutOfMemory several times  when tries to get a string content - in this moment rope transformed into real string
And from my observation s = s + '..' is a common pattern in JS today, nobody uses array.push / array.join anymore

Offline

#7 2021-03-24 20:44:01

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 13,368
Website

Re: QuickJS performance

Yes, for SM/V8 it is the case.
But not for QuickJS - it still has better performance with join().

Offline

Board footer

Powered by FluxBB