<midiclub@tiscali.de> wrote in message news:b9vvrj$r9r$1@digitaldaemon.com...
> In article <b9uh9j$2fls$1@digitaldaemon.com>, Martin M. Pedersen says...
> For that, the
> complete parsed source of the application and used libraries is contained
in
> memory during the project compilation. This causes the whole library code
to be
> re-parsed once per project compilation, but not more often than that.
Maybe
> Walter could implement dumping of the parse trees to disk - this would be
a
> great and major optimisation.

That was the original plan, but the compiler parses so fast it wasn't justifiable to make the effort.

D compiler is really really fast.  Gotta hand it to ya.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ba312c$uav$1@digitaldaemon.com...
>
> > re-parsed once per project compilation, but not more often than that.
Maybe
> > Walter could implement dumping of the parse trees to disk - this would
be a
> > great and major optimisation.
>
> That was the original plan, but the compiler parses so fast it wasn't justifiable to make the effort.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:ba36nl$1430$1@digitaldaemon.com...
> D compiler is really really fast.  Gotta hand it to ya.

Thanks. I haven't even expended any effort tuning it for speed. I just structured the language so it would be fast to parse.

Walter wrote:

> Thanks. I haven't even expended any effort tuning it for speed. I just structured the language so it would be fast to parse.

The whole thing is fast.  It's so fast I couldn't tell the difference from doing something like:

$ export DMD=/path/to/blah

and running the compiler itself.

DMC++ is also super fast.  What would you attribute that to?

"Garen Parham" <nospam@garen.net> wrote in message news:ba4f4p$29kc$1@digitaldaemon.com...
> DMC++ is also super fast.  What would you attribute that to?

Profile, profile, profile!

Walter wrote:
> Thanks. I haven't even expended any effort tuning it for speed. I just
> structured the language so it would be fast to parse.

assert (Walter == GeniousWizard);

AND LET TEH WORLD CRASH IF THIS ASSERT FAILS!
:>

-i.

Walter wrote:


> 
> Profile, profile, profile!


Thats it?  I was thinking maybe you'd say you had some ingenuous bottom-up strategies tightly knit with the target/languages or something. :)

Walter wrote:
> 
> "Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EC32D89.2F4CD480@chello.at...
> > I agree, esp. with the need to resolve the one-to-one relationship between source file (module) and object file.
> >
> > One way to do this could be manually, by using a
> >   #pragma split
> > which could produce from a source file
> >   module.d:
> >   ...independent code, part 1
> >   #pragma split
> >   ...independent code, part 2
> >   #pragma split
> >   ...independent code, part 3
> > three separate object files (via a compiler "split" option)
> >   module_001.obj
> >   module_002.obj
> >   module_003.obj
> > for inclusion into libaries.
> 
> The D compiler automatically generates COMDATs for each function in a module, so they are individually linked in. It's equivalent to doing the above.

Hey, that's great! I tried to check it and it seems to work. Is the a linker option that gives a more detailed list of the code (text) area?

> > This would allow to reduce the footprint of D applications:
> > - embedded people won't consider D with its current 60K
> >   minimium exe size (they think in the range 1-8K).
> 
> The D footprint is about 24k larger than the equivalent C footprint.

Both seems a bit large given that the linker removes dead code.

> > - needing Win32 structs you will need to compile and link
> >   some windows.d file into your application. Its 500 init
> >   default structures add about 30K. This could be splitted
> >   into reasonable parts without creating 500 independent
> >   source files to have a space optimized interface.
> 
> Actually, I need to remove the need to link in the struct inits for 0 initted structs.

That would be great for the Win32 API, because otherwise one has to work around this.

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EC938EB.5E35CB39@chello.at...
> > The D compiler automatically generates COMDATs for each function in a module, so they are individually linked in. It's equivalent to doing the above.
> Hey, that's great! I tried to check it and it seems to work. Is the a linker option that gives a more detailed list of the code (text) area?

/MAP


> > > This would allow to reduce the footprint of D applications:
> > > - embedded people won't consider D with its current 60K
> > >   minimium exe size (they think in the range 1-8K).
> > The D footprint is about 24k larger than the equivalent C footprint.
> Both seems a bit large given that the linker removes dead code.

They're a bit large on Win32 systems because (unfortunately) there is a lot of code always linked in that deals with exceptions thrown from VC++ compiled DLLs. This is necessary so that DMC++ code can call DLLs built with VC++ and catch exceptions thrown by it. This code has no relevance for embedded systems, and so won't be there.


> > > - needing Win32 structs you will need to compile and link
> > >   some windows.d file into your application. Its 500 init
> > >   default structures add about 30K. This could be splitted
> > >   into reasonable parts without creating 500 independent
> > >   source files to have a space optimized interface.
> > Actually, I need to remove the need to link in the struct inits for 0 initted structs.
> That would be great for the Win32 API, because otherwise one has to work around this.

I've got a lot of things like this that need to be done.

"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:ba0irh$1g5e$1@digitaldaemon.com...
> .. I'm able to find "This should not be in the executable" in the executable. I have tried this with the linker of MSVC6 and DMC.

You need to compile with -Nc (function level linking). It's off by default for C because some legacy C will fail with -Nc. The D compiler does this automatically.