You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 2021-03-23 19:25:11
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.695sSpiderMonkey
Offline
#2 2021-03-23 19:32:26
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 - 53MbSo 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
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,218
Re: QuickJS performance
It seems that https://github.com/tondrej/chakracore-delphi is not in the benchmark list? 
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
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
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
Pages: 1