I recall someone once getting a Squeak Smalltalk image down to 384k. However, there was a Digitalk originated project called "Firewall" that could produce Smalltalk images as small as 45k, suitable for writing command-line programs, even on early 90's machines. (Even recent versions of VisualWorks can get their memory footprint down around to that of Perl 5's, and even beat Perl 5 in terms of startup speed, provided you are prepared to dig around and shut a whole lot of things off.)
That's fairly impressive. Perl 5 is pretty quick to start:
# perl -E 'my $cmd = shift; use Time::HiRes; my @times; for (1..10) { my $start=Time::HiRes::time; my $out = system($cmd); my $stop = Time::HiRes::time; die if $out>>8; my $time = $stop - $start; push @times, $time; printf "%0.4f\n", $time; } @times = sort {$a<=>$b} @times; @times = @times[1..8]; my $cumulative=0; $cumulative += $_ for @times; my $average = $cumulative/8; printf "Average time of 10 runs of \"%s\", dropping best and worst: %0.4f\n", $cmd, $average;' "perl -e '1;'"
0.0039
0.0032
0.0031
0.0031
0.0032
0.0035
0.0036
0.0030
0.0033
0.0032
Average time of 10 runs of "perl -e '1;'", dropping best and worst: 0.0033
That's Perl 5.22.1. For "python -c '1'" (Python 2.7.5) I get 0.0173. A minimal C program (just return success from main after including stdlib and stdio) built with default gcc opts is <9k in size, and vacillates between averaging 0.0007 and 0.0010 in the the benchmark above when I run it.
That perl code that Time:HiRes to measure the time it takes to start perl via system(), which includes the time it takes to fork a shell and parse the command and then fork to spawn perl. `time perl -e '1;'` is more representative of the raw perl startup time, which on my machine is reliably 0.002 real seconds, ⅔ of your times (that is, there's a lot of overhead in your measurement).
A minimal C program (just return success from main after including stdlib and stdio)
You do realize that a "including stdlib and stdio" means nothing for a C program, right? These are, literally, just the API definitions, in the Oracle-vs-Google Android sense. The default gcc options probably produced a dynamic executable; if you compile it statically, you might be able to shave a few more microseconds in startup time.
> includes the time it takes to fork a shell and parse the command and then fork to spawn perl.
The only difference from the shell builtin time, or /usr/bin/time, should be the shell startup and exec call. Every command is fork+exec, so you can't really get away from that. If I really cared, I would try to account for that, but I don't. I thought it was pretty obvious that I wasn't being very rigorous. I just did the minimum to make the values I got not useless.
> which on my machine is reliably 0.002 real seconds, ⅔ of your times
And on mine it fluctuates between 0.002 and 0.009. You mention your times relative to my times, but that's useless. I ran mine on a 512mb VPS. The only relevant measure to determine overhead would be my method vs the shell builtin. Is that what you were actually referring to?
> You do realize that a "including stdlib and stdio" means nothing for a C program, right?
Truthfully, so I wouldn't have to remember the setup for C, I just googled "minimal C program" and removed the printf it had. I only mentioned the includes for completeness sake, and I didn't want to clutter the comment with the source.
> if you compile it statically, you might be able to shave a few more microseconds in startup time
Possibly, but that's not really what I was trying to convey. I was just pointing out that a minimal Perl program isn't slower than a minimal C program, and it's notable if you can get your startup times close to that for a system with a virtual machine.
Err "minimal Perl program isn't slower than a minimal C program" was supposed to be "minimal Perl program isn't that much slower than a minimal C program".
