in the D docs, it says that "one cause for slow compile times in C/C++ is recompiling tens of thousands of lines of header files every time" or something along those lines.

if i'm not mistaken, it has to parse any imported modules into a symbol table.  granted, it's not compiling them, but it's still parsing *every* imported module *every time*.

it seems a little counterintuituve, though i'm not sure what the alternative would be.


secondly, say you're using a batch file to make your program, and in it you have something along the lines of:

\dmd\bin\dmd myfile.d mymodule.d -c

this will make 2 object files, one for the main file and one for the module. if you then want D to just link the object rather than recompiling the module, you then must change the command line:

\dmd\bin\dmd myfile.d mymodule.obj

it "imports" the module from the main file, thus parsing the symbols, and then links to the module.

every time you change the module, you would have to recompile it into an obj, unless you want to do this:

\dmd\bin\dmd myfile.d mymodule.d

thus recompiling both files every time, making things easier but slower.

is there any way to automatically detect which modules need to be rebuilt? i suppose an IDE would help here ;)

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:ccvjhq$13t9$1@digitaldaemon.com...
> in the D docs, it says that "one cause for slow compile times in C/C++ is recompiling tens of thousands of lines of header files every time" or something along those lines.
>
> if i'm not mistaken, it has to parse any imported modules into a symbol table.  granted, it's not compiling them, but it's still parsing *every* imported module *every time*.
>
> it seems a little counterintuituve, though i'm not sure what the
alternative
> would be.

True if you compile each module separately. But you can lump them all on one command line, and then they only get scanned once eacy.

> secondly, say you're using a batch file to make your program, and in it
you
> have something along the lines of:
>
> \dmd\bin\dmd myfile.d mymodule.d -c
>
> this will make 2 object files, one for the main file and one for the
module.
> if you then want D to just link the object rather than recompiling the module, you then must change the command line:
>
> \dmd\bin\dmd myfile.d mymodule.obj
>
> it "imports" the module from the main file, thus parsing the symbols, and then links to the module.
>
> every time you change the module, you would have to recompile it into an obj, unless you want to do this:
>
> \dmd\bin\dmd myfile.d mymodule.d
>
> thus recompiling both files every time, making things easier but slower.
>
> is there any way to automatically detect which modules need to be rebuilt? i suppose an IDE would help here ;)

Using makefiles is the typical solution. www.digitalmars.com/ctg/make.exe

Jarrett Billingsley wrote:

> thus recompiling both files every time, making things easier but slower.

Actually, I believe it's still faster in most cases. If you have very many files, the one file at a time approach might be better if some dependency checking is done making sure only changed files are recompiled. The dependency checking slows down the process though. On linux, due to slower linking, the situation might be quite different.

Lars Ivar Igesund

In article <ccvjhq$13t9$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>in the D docs, it says that "one cause for slow compile times in C/C++ is recompiling tens of thousands of lines of header files every time" or something along those lines.
>
>if i'm not mistaken, it has to parse any imported modules into a symbol table.  granted, it's not compiling them, but it's still parsing *every* imported module *every time*.

Walter says that the parse process is much, much faster than compilation, and so shouldn't worry anyone.

I discovered, during the course of putting etc.unicode.unicode together, however, that this isn't quite as true as we'd like to believe. etc.unicode.unicode is a rather unusual beast, of course, consisting of hundreds of source-files, some containing const array literals thousands of lines long. For something like this, even /parsing/ them is nightmarishly slow. Fortunately, I have now persuaded my robot to create stripped headers, which now of course compile like lightning.





>is there any way to automatically detect which modules need to be rebuilt?

Most people use "make" for this - or some other system which achieves the same effect.

Me, I have a custom build script written in PHP which figures out what to compile by recursively parsing import statements, starting from the file containing main(). It works out all the dependencies, and what needs to be rebuilt and what doesn't, and then gets on with it. As an added bonus it also figures out what libraries to link with. (It's pretty neat actually, because a new file becomes part of my project simply be being mentioned in an import statement - no messing about with makefiles needed).


If you're not comfortable with writing your own scripts, and you're not comfortable with make, there are other alternatives, which I'm sure other people will suggest.

Arcane Jill

thank you all :)  i'll look into make.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cd04t2$241v$1@digitaldaemon.com...
> For something like this, even /parsing/ them is nightmarishly slow.
Fortunately,
> I have now persuaded my robot to create stripped headers, which now of
course
> compile like lightning.

Hm, that's disconcerting that you needed to effectively "undo" one of D's primary features ("no header files!") to make D compile a complex app.

However, it's cool that header files are treated as an "optimization" in D, rather than a necessity (as in C/C++).

Is there any way to automate this process -- perhaps flag certain D modules (possibly a #pragma in the file?) so the compiler automatically performs this optimization?  Second best, can we package a header stripping tool with DMD so it can be available to everyone?

-david

In article <cd115g$m7m$1@digitaldaemon.com>, David Barrett says...

>Hm, that's disconcerting that you needed to effectively "undo" one of D's primary features ("no header files!") to make D compile a complex app.

It's not a complex app. Actually, it's a very simple bunch of table lookups. It's just the sheer size and number of tables that slow things down, so header files in this case just shorten compilation times, that's all.


>However, it's cool that header files are treated as an "optimization" in D, rather than a necessity (as in C/C++).

Yeah, I like that too.



>Is there any way to automate this process -- perhaps flag certain D modules (possibly a #pragma in the file?) so the compiler automatically performs this optimization?

Without clairvoyance, I don't see how it can. But then, I've never written a compiler. I guess Walter would know if it's feasable.


>Second best, can we package a header stripping tool with DMD so it can be available to everyone?

Walter says that would be an easy thing to create, but so far no-one's volunteered to make it. (You want the job?).

The people most interested in this would be closed-source developers who want to hide their source code. I'm very much an open-source advocate, myself, so I don't think I'd be particularly interested in such a tool. (The Unicode thing is robot-generated, so header files just get created alongside the full source files).



Arcane Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cd04t2$241v$1@digitaldaemon.com...
> etc.unicode.unicode is a rather unusual beast, of course, consisting of
hundreds
> of source-files, some containing const array literals thousands of lines
long.
> For something like this, even /parsing/ them is nightmarishly slow.
Fortunately,
> I have now persuaded my robot to create stripped headers, which now of
course
> compile like lightning.

If you can give me a canonical test case for this, I'll look and see if the lexer has any stupid bottlenecks in it that can be fixed.