Scripting Language Startup Overhead

https://git.sr.ht/~q3cpma/interp_overhead

6 7 2 years ago

git.sr.ht

I don't remember where I saw the inspiration for that, but I greatly extended the idea at some point. After a small cleanup today, I thought it could bring some good discussion.

Here are the raw numbers:

  Interpreter                Syscall count  Real time (s; x100)  User time  Kernel time  Max resident memory (KB)
  bash 5.2.37                156            0.07                 0.03       0.04         3596
  busybox ash 1.36.1         35             0.02                 0.01       0.01         1556
  dash 0.5.12                33             0.02                 0.01       0.00         1556
  ksh PD KSH v5.2.14         88             0.05                 0.03       0.02         2376
  mksh R59                   75             0.04                 0.02       0.01         1824
  yash 2.57                  93             0.05                 0.03       0.02         3132
  zsh 5.9                    274            0.08                 0.04       0.03         3792
  busybox awk 1.36.1         19             0.02                 0.01       0.01         1556
  mawk 1.3.4_20240905        58             0.04                 0.02       0.01         2444
  gawk 5.3.1                 103            0.06                 0.03       0.03         3568
  nawk 20230909              58             0.04                 0.02       0.01         2592
  python 2.7.18              629            0.45                 0.31       0.13         6484
  python 3.12.8              389            0.74                 0.56       0.18         9636
  perl 5.40                  175            0.08                 0.02       0.06         5088
  raku v2024.10              657            15.40                14.49      4.07         148148
  tclsh 8.6                  140            0.15                 0.09       0.06         5164
  jimtcl 0.83                109            0.12                 0.05       0.06         4052
  lua 5.1.5                  83             0.06                 0.03       0.03         2624
  lua 5.3.6                  83             0.06                 0.03       0.02         2620
  lua 5.4.6                  83             0.06                 0.03       0.02         2644
  luajit 2.1.1716656478      76             0.05                 0.03       0.02         2680
  nodejs v22.4.1             743            1.65                 1.14       0.52         40664
  chez scheme 10.0.0         350            3.70                 2.28       1.42         47568
  petite chez scheme 10.0.0  304            2.30                 1.42       0.87         31056
  gauche 0.9.15              2530           3.43                 9.52       1.11         25228
  stklos 2.00                280            2.78                 2.53       0.25         12368
  guile 3.0.10               1512           1.50                 2.02       0.67         16148
  guile 3.0.10 (compiler)    3718           5.28                 7.55       1.50         33728
  ecl 23.9.9                 3286           3.61                 5.09       0.91         12268
  sbcl 2.4.11                241            0.24                 0.06       0.18         19008
  clisp 2.49.92              399            0.48                 0.20       0.25         9556
  ccl 1.13                   293            0.36                 0.11       0.21         16456

BoingBoomTschak4• 2 years ago

(if anyone knows what's up with raku, I'm all ears, because this is a disaster)

lizmat2• 2 years ago

Startup time is not the strong point of Rakudo. And it will be a long time before it will.

Beyond startup, performance definitely has attention of the core developers: that's when hot code gets inlined, and JITted to machine code if you're on Intel hardware. But before that, currently not so much.

The best possible startup time that could potentially be reached in the current implementation of Rakudo, is the bare startup time of NQP in which Rakudo is basically implemented. Compare NQP on an Intel 2.4 GHz i9 on MacOS:

% time nqp -e '' real 0.04s user 0.03s sys 0.01s

with:

% time rakudo -e '' real 0.15s user 0.15s sys 0.03s

With NQP taking about 16MB of memory.

Raku as a language is selected for its features, its community and possibly for its promise. Whether that is a disaster or not, is up to the user.

Finally, if you want fast startup, don't use a scripting language.

BoingBoomTschak4• 2 years ago

Finally, if you want fast startup, don't use a scripting language.

Huh? Isn't startup speed one of the points of simpler, less optimized interpretation strategies? I mean, unless you compare it to AOT compilation, which is another story. Those numbers show that Perl and Tcl, both "full featured" scripting languages, don't have the least issue on the matter.

I'm not the kind to freely rain on parades, especially when Raku is already not a popularity king, but I don't think my use of the word "disaster" was unfounded, even if not "very nice".

frou_dh• 2 years ago

Nice job. I'd like to add that surprisingly OCaml can be considered a Unix scripting language because it supports both #! shebang scripts and one-shot evaluations e.g. `ocaml -e 'print_endline "hello"'`. In these modes it uses bytecode rather than native compilation.

BoingBoomTschak4• 2 years ago

That is interesting because I thought OCaml only had a native compiler.

Scripting Language Startup Overhead

Related Stories