Performance benchmarks about duktape HOT 11 CLOSED

Duktape is a traditional bytecode interpreter: code is compiled into a custom bytecode format and executed from that. There is no JIT and no current plans to implement it, as it's quite a portability issue. What's more, just a JIT wouldn't be that great an improvement unless also property accesses were optimized with something like the "hidden classes" used by e.g. V8, so the execution model would be quite different.

The dropoff in performance from V8 to Duktape would be over 10x in most cases.

from duktape.

I have plans to run some benchmarks for HTTP servers comparing node.js, luvit.io and dukluv.io. I understand that pure interpreters are hard to make fast. In fact I'm quite impressed with how fast it is. My own interpreters were much slower than duktape. For my dukluv http server I'll probably bind https://github.com/joyent/http-parser the same as node.js does. So most the heavy work will be done in libuv and http-parser. I expect performance to be acceptable for I/O heavy operations. I might even add in a template engine to mix some moderate script execution cost into the benchmark.

from duktape.

@creationix It'll be interesting to hear the results!

There's going to be performance work optimizing the bytecode executor and I think it can be improved a lot from its current state - but it will still be interpreted so there's a limit to what can be achieved.

I would hope most programs using Duktape for embedded scripting would do heavy lifting with C code and use Duktape to provide the flexible glue tying the C stuff together.

from duktape.

Well, I may have some kind of server benchmarks, it's not a fair comparison since I don't handle http responses like node, just direct print to the socket.

As I said it's not a fair comparison but it might show you the beauty of duktape, especially for memory usage.

I used apache ab server test, with simple hello world, in fact it was "Hi there" :)

first attempt
ab -n 1000000 -c 200 http://127.0.0.1:9090/test

duktape based plais http server
memory usage : ~ 2mb

Concurrency Level:      200
Time taken for tests:   249.031 seconds
Complete requests:      1000000
Total transferred:      86000000 bytes
HTML transferred:       8000000 bytes
Requests per second:    4015.56 [#/sec] (mean)
Time per request:       49.806 [ms] (mean)
Time per request:       0.249 [ms] (mean, across all concurrent requests)
Transfer rate:          337.24 [Kbytes/sec] received

node
first & second attempt failed, my fault indeed
third attempt
memory usage : ~ 43mb

Concurrency Level:      200
Time taken for tests:   357.172 seconds
Complete requests:      1000000
Total transferred:      84000000 bytes
HTML transferred:       9000000 bytes
Requests per second:    2799.77 [#/sec] (mean)
Time per request:       71.434 [ms] (mean)
Time per request:       0.357 [ms] (mean, across all concurrent requests)
Transfer rate:          229.67 [Kbytes/sec] received

Notes

• Tests run on a windows machine
• Event loop used is really tiny and uses select for polling, not completion ports
• Headers parsing just like node implemented using their C http_parser library.
• I'm new to C so my work has a big room for improvement when someone more experienced involve :)

See that duktape kept things well around ~2mb of memory usage, this is really amazing, but of course when benching javascript loops for example against node things will be different, which also is not fair to bench jit compiler against interpreted compiler, I'm going to try to do some benchmarks against perl and paste the results here, and as @svaarala said you can always deploy hot parts of your code in c, I found code flowing between javascript and C very easy and convenient, thanks to duktape great documentation and hand crafted API.

from duktape.

@mamod if you want to test using completion ports, my libuv bindings for duktape are complete enough to create a tcp server. https://github.com/creationix/dukluv/blob/master/tcp-echo.js Though I have link issues on windows I haven't figured out yet.

from duktape.

@creationix looks interesting, I'm just wondering if select beats node then I'm sure completion ports will work even better especially with higher concurrency tests, so I'm going to try dukluv to benchmark again, I have a linux box at home :)

from duktape.

Some more "in the field" reporting :)

Background: I need to parse Javascript to AST so I can traverse it natively. Ideally, the parser would be native as speed is important, though that's quite involved to implement. I parse the Javascript code and then use JSON.stringify to generate a string for native to consume with rapidjson

For parsing, I have been using:
https://github.com/marijnh/acorn/blob/master/acorn.js

As a benchmark, I have it parsing this Javascript file: https://github.com/ariya/esprima/blob/master/esprima.js

Duktape
Acorn parse time: 388ms
JSON.stringify time: 334ms

I pulled down SpiderMonkey master and got it compiling in the project. This is what I am seeing with it:

SpiderMonkey (master as of 12-5-2014)
Acorn parse time: 249ms
JSON.stringify time: 36ms

The takeaway for our project, is that Duktape rocks 👍

It really holds its own on the parsing, the JSON.stringify is however quite slow. So, I am planning to split the parsing up by running it as a coroutine and tossing some yield's into Acorn (so it doesn't freeze the program for 400ms when parsing). I will probably need to walk the parsed object using Duktape's C API, as Duktape's JSON.stringify is too slow.

from duktape.

@JoshEngebretson Nice to hear it performs reasonably :)

The current JSON parse/stringify implementation has been written to fulfil all the small requirements in the specification in a single algorithm and it should be straightforward to make it much faster for common cases. Most likely there would be a fast path serializer for common cases (optional to preserve footprint for low memory devices).

JSON is an important target for performance optimization. I'm anxious to get some time to work on the performance backlog, but there are a few more important features first on the roadmap :-)

from duktape.

No activity on this issue in a while so I'll close this one.

from duktape.

How do you compile the split up sources post version 1.0 using Visual Studio 2010?

from duktape.

@black13 There should be nothing special:

• Include path must be set up so that duktape.h can be found (src-separate/ in your case).
• Compile all .c files in src-separate/ along with your application files.

Do you have a specific problem you're running into?

from duktape.