Empy program running time

[Steven Schveighoffer]

On Fri, 19 Aug 2011 01:29:05 -0400, Marco Leise <Marco.Leise at gmx.de> wrote:

> 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.

I agree for simple frequently used utilities, the initialization time can
be bad.  But I have actually written scripting utility programs
(ironically, to help boot a custom linux OS that I built), and I didn't
notice terrible slowdown.

Another question is, would someone who is using D be more likely to write
their script in D, and simply use D libraries, or write a "file" utility
in D, and use a shell script?

It all depends on the situation, and to me, .11 seconds isn't that
terrible.  If it can be improved, then I think we should do it, but IMO
it's not a critical piece right now.

-Steve