Empy program running time

[Marco Leise]

Am 29.07.2011, 17:23 Uhr, schrieb Steven Schveighoffer  
<schveiguy at yahoo.com>:

> On Fri, 29 Jul 2011 10:50:52 -0400, bearophile  
> <bearophileHUGS at lycos.com> wrote:
>
>> Steven Schveighoffer:
>>
>>> For example, D needs to call all the module ctors and do the import  
>>> cycle
>>> detection algorithm.
>>
>> Even for an empty program?
>
> Yes.  I bet even an empty program has on the order of 50 module  
> ctor/dtors to run.  All the runtime can contain module ctor/dtors, and  
> those modules are compiled in no matter what.  Plus dmd adds hidden  
> modules with ctor/dtors.
>
> There are other initializations, such as the GC, setting up the main  
> thread, etc.
>
>>> 0.11 seconds is not unreasonable.
>>
>> It means about 170_000_000 CPU clock ticks, to me it seems a lot.
>
> I guess if you want to have an empty program benchmark?  It doesn't seem  
> to mean much to me...
>
> If it was on the order of seconds, I'd agree with you.  .11 seconds is  
> barely noticeable.

You think in the wrong category. Imagine where this would matter, where  
you would invoke a program multiple times. From the top of my head there  
is batch execution. If your program is a converter of some sort that takes  
one input file and one output file at a time and someone writes a script  
to convert all files in a directory structure. Every 545 files you get an  
additional minute of initialization on that test machine! If the actual  
conversion algorithms is fast and the files are small (i.e. converting  
character encodings in text files) this is well noticeable.
A more abstract idea is the boot process of an old-school Linux  
installation. Every start script (mail server, keyboard layout, swap,  
logging, ...) invokes the shell several times. If the shell was written in  
D it would slow down the boot process more than necessary. But here  
efforts were made to reduce the amount of processes spawned during the  
boot process so this can not be a valid argument.
The "file" utility opens files and prints their mime-type looking at magic  
bytes and other identifiers. This is another good example of a program  
that may be run on a large number of files, but doesn't run for long. It  
could be used by a file system browser to display the file-type of every  
file in a directory.

>>> But I'll also stress that timings at this precision can be fairly  
>>> volatile.
>>
>> I think this timing precision is not so bad.
>
> What I mean is, the timing for a program can easily vary by 10ths of a  
> second between runs, depending on what's happening on the computer.   
> Make sure you do an average, and not a single run to do these kinds of  
> tests.
>
> -Steve