NPL Runtime Performance Compare¶
High-Performance JIT Compiler¶
NPL syntax is 100% compatible with Lua, therefore it can be configured to utilize JIT compiler (Luajit). In general, luajit is believed to be one of the fastest JIT compiler in the world. It’s speed is close to C/C++, and can even out-perform static typed languages like java/C#. It is the fastest dynamic language in the world. However, special care needs to be taken when writing test cases, since badly written test case can make the same code 100 times slower.
The following micro-benchmark results were obtained on a single core (serial execution) on an Intel(R) Xeon(R) CPU E7-8850 2.00GHz CPU with 1TB of 1067MHz DDR3 RAM, running Linux:
Figure: benchmark times relative to C (smaller is better, C performance = 1.0).
C and Fortran compiled by gcc 5.1.1, taking best timing from all optimization levels (-O0 through -O3). C, Fortran, Go. Python 3 was installed from the Anaconda distribution. The Python implementations of rand_mat_stat and rand_mat_mul use NumPy (v1.9.2) functions; the rest are pure Python implementations. Benchmarks can also be seen here as a plot created with Gadfly.
NPL Database Performance¶
More information, please see UsingTableDatabase
Following is tested on my Intel-i7-3GHZ CPU. See test folder for test source code.
Run With Conservative Mode¶
Following is averaged value from 100000+ operations in a single thread
- Random non-index insert:
- Async API tested with default configuration with 1 million records on a single thread.
- Round trip latency call:
- Blocking API:
- Non-blocking API:
85 query/s(due to NPL time slice)
- i.e. Round strip means start next operation after previous one is returned. This is latency test.
- Blocking API:
- Random indexed inserts:
- i.e. start next operation immediately, without waiting for the first one to return.
- Random select with auto-index:
- i.e. same as above, but with findOne operation.
- Randomly mixing CRUD operations:
- i.e. same as above, but randomly calling Create/Read/Update/Delete (CRUD) on the same auto-indexed table.
- Mixing read/write can be slow when database grows bigger. e.g. you can get
18000 CRUD/sfor just 10000 records.
NPL Web Server Performance¶
The following is done using ApacheBench (AB tool) with 5000 requests and 1000 concurrency on a 1 CPU 1GB memory virtual machine. The queried content is http://paracraft.wiki/, which is a fairly standard dynamic web page.
root@iZ62yqw316fZ:/opt/paracraftwiki# ab -n 5000 -c 1000 http://paracraft.wiki/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking paracraft.wiki (be patient).....done Finished 5000 requests Server Software: NPL/1.1 Server Hostname: paracraft.wiki Server Port: 80 Document Path: / Document Length: 24736 bytes Concurrency Level: 1000 Time taken for tests: 3.005 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 124730000 bytes HTML transferred: 123680000 bytes Requests per second: 1664.05 [#/sec] (mean) Time per request: 600.944 [ms] (mean) Time per request: 0.601 [ms] (mean, across all concurrent requests) Transfer rate: 40538.43 [Kbytes/sec] received