On Sat, 20 Dec 2008 16:28:40 +0300, Bill Baxter <wbaxter@gmail.com> wrote:

> On Sat, Dec 20, 2008 at 10:01 PM, Denis Koroskin <2korden@gmail.com> wrote:
>> On Sat, 20 Dec 2008 15:39:08 +0300, Bill Baxter <wbaxter@gmail.com> wrote:
>>
>>> On Sat, Dec 20, 2008 at 9:11 PM, Denis Koroskin <2korden@gmail.com> wrote:
>>>>
>>>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com>
>>>> wrote:
>>>>
>>>>> For me, V1.038 compiles my code but takes a really really really long
>>>>> time to do so.
>>>>>
>>>>> It now takes  1 min 20 secs for a full build, when it used to compile
>>>>> in 13 seconds.
>>>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>>>
>>>>> (building with DSSS and tango)
>>>>>
>>>>> --bb
>>>>>
>>>>
>>>> I generally make all my imports private and run a command line tool that
>>>> strips unnecessary imports once in a while to minimize intermodular
>>>> dependencies. Maybe it could help in your case, too?
>>>>
>>>
>>> I'd love to have an unnecessary import finder tool.  How does that work?
>>>
>>> --bb
>>
>> It's easy: remove an import and try if it still works :)
>
> Oh.  ok.  Well, removing things and trying to recompile is more or
> less what I do now.  That's not really what I'd call a "tool".  That's
> what I'd call "doing it manually".
>
> --bb

No, it's fully automated.

On Sat, Dec 20, 2008 at 10:36 PM, Denis Koroskin <2korden@gmail.com> wrote:
> On Sat, 20 Dec 2008 16:28:40 +0300, Bill Baxter <wbaxter@gmail.com> wrote:
>
>> On Sat, Dec 20, 2008 at 10:01 PM, Denis Koroskin <2korden@gmail.com> wrote:
>>>
>>> On Sat, 20 Dec 2008 15:39:08 +0300, Bill Baxter <wbaxter@gmail.com> wrote:
>>>
>>>> On Sat, Dec 20, 2008 at 9:11 PM, Denis Koroskin <2korden@gmail.com> wrote:
>>>>>
>>>>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com> wrote:
>>>>>
>>>>>> For me, V1.038 compiles my code but takes a really really really long time to do so.
>>>>>>
>>>>>> It now takes  1 min 20 secs for a full build, when it used to compile
>>>>>> in 13 seconds.
>>>>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>>>>
>>>>>> (building with DSSS and tango)
>>>>>>
>>>>>> --bb
>>>>>>
>>>>>
>>>>> I generally make all my imports private and run a command line tool
>>>>> that
>>>>> strips unnecessary imports once in a while to minimize intermodular
>>>>> dependencies. Maybe it could help in your case, too?
>>>>>
>>>>
>>>> I'd love to have an unnecessary import finder tool.  How does that work?
>>>>
>>>> --bb
>>>
>>> It's easy: remove an import and try if it still works :)
>>
>> Oh.  ok.  Well, removing things and trying to recompile is more or less what I do now.  That's not really what I'd call a "tool".  That's what I'd call "doing it manually".
>>
>> --bb
>
> No, it's fully automated.

Ah, now I get it.

--bb

Hello Denis,

> On Sat, 20 Dec 2008 15:39:08 +0300, Bill Baxter <wbaxter@gmail.com>
> wrote:
> 
>> On Sat, Dec 20, 2008 at 9:11 PM, Denis Koroskin <2korden@gmail.com>
>> wrote:
>> 
>>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com>
>>> wrote:
>>> 
>>>> For me, V1.038 compiles my code but takes a really really really
>>>> long time to do so.
>>>> 
>>>> It now takes  1 min 20 secs for a full build, when it used to
>>>> compile
>>>> in 13 seconds.
>>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>> (building with DSSS and tango)
>>>> 
>>>> --bb
>>>> 
>>> I generally make all my imports private and run a command line tool
>>> that strips unnecessary imports once in a while to minimize
>>> intermodular dependencies. Maybe it could help in your case, too?
>>> 
>> I'd love to have an unnecessary import finder tool.  How does that
>> work?
>> 
>> --bb
>> 
> It's easy: remove an import and try if it still works :)
> I recompile that file only and since all the imports are private, it
> generally doesn't break other files.
> The only exception - templates. They aren't fully analyzed until
> instanciated and therefore some imports may be removed even if they
> are  necessary. A simple tag prevents an import from removal:
> 
> private import std.algorithm; // force
> 
> Works about 3 minutes to remove all redundant imports from DWT.
> 


So you've tried this with dwt?  Were you able to see if it affected the final binary size or speed of compilation for dwt projects?

Removing all redundant imports in DWT is something we should see happen in the repository. :)

-JJR

Denis Koroskin wrote:
> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com> wrote:
>
>> For me, V1.038 compiles my code but takes a really really really long
>> time to do so.
>>
>> It now takes 1 min 20 secs for a full build, when it used to compile
>> in 13 seconds.
>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>
>> (building with DSSS and tango)
>>
>> --bb
>>
>
> I generally make all my imports private and run a command line tool that
> strips unnecessary imports once in a while to minimize intermodular
> dependencies. Maybe it could help in your case, too?

When programming in Java, Eclipse knows to handle all of this for you. it will suggest adding missing imports, it can remove unused imports and it can convert a foo.bar.* into a list of the specific modules you actually used in the code.
I wish that kind of tool would be available for D. Is this functionality implemented in descent? if not, is it planned?

I do realize that it's more difficult to do this for D than it is for Java, because of Conditional compilation and other issues already mentioned in this thread. But it would be awesome if I could just write:

Stdout("whatever").newline;

and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list of imports.

--Yigal

On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100@gmail.com> wrote:

> Denis Koroskin wrote:
>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com> wrote:
>>
>>> For me, V1.038 compiles my code but takes a really really really long
>>> time to do so.
>>>
>>> It now takes 1 min 20 secs for a full build, when it used to compile
>>> in 13 seconds.
>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>
>>> (building with DSSS and tango)
>>>
>>> --bb
>>>
>>
>> I generally make all my imports private and run a command line tool that
>> strips unnecessary imports once in a while to minimize intermodular
>> dependencies. Maybe it could help in your case, too?
>
> When programming in Java, Eclipse knows to handle all of this for you. it will suggest adding missing imports, it can remove unused imports and it can convert a foo.bar.* into a list of the specific modules you actually used in the code.
> I wish that kind of tool would be available for D. Is this functionality implemented in descent? if not, is it planned?
>
> I do realize that it's more difficult to do this for D than it is for Java, because of Conditional compilation and other issues already mentioned in this thread. But it would be awesome if I could just write:
>
> Stdout("whatever").newline;
>
> and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list of imports.
>
> --Yigal

You should watch Descent videos on youtube, it is *much* smarter that that!

http://www.youtube.com/user/asterite

On Sat, Dec 20, 2008 at 12:50 PM, Denis Koroskin <2korden@gmail.com> wrote:
> You should watch Descent videos on youtube, it is *much* smarter that that!
>
> http://www.youtube.com/user/asterite
>

Wow, that's so awesome!

Walter Bright schrieb:
> Sönke Ludwig wrote:
>> In my project compilation takes now several minutes for some files which compiled in about a second with 2.021. I stopped the compilation of the whole project after about 2 hours (took 2 min at most on 2.021).
>>
>> I'll try to track this down when I get the time, but i doubt that those times get anywhere near those of the original.
> 
> Do you have modules that recursively import themselves, and instantiate a lot of templates?

There were some import cycles and I've had some time now to remove all of them. There might be a small improvement but it feels just as slow as before (still multiple minutes for some files).

In the particular region of the library there is a Variant template in use at two places as a typedef: "typedef Variant!(TypeEnum, type1, type2, ..., type8);". This would be my main suspect when it comes to templates. However, compiling the Variant module alone or a small module only using Variant takes a fraction of a second.

I have attached the output of a CodeAnalyst profiling run. The file shows the hotspot section during the first 60 seconds of compiling one of the files. Percentages have to be multiplied roughly by 2 because this is a dual core system.

Sönke Ludwig schrieb:
>  Percentages have to be multiplied roughly by 2 because
> this is a dual core system.
> 

Hm, ignore that part.. they are multiplied by 2 already...

Denis Koroskin wrote:
> On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100@gmail.com>
> wrote:
>
>> Denis Koroskin wrote:
>>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com>
>>> wrote:
>>>
>>>> For me, V1.038 compiles my code but takes a really really really long
>>>> time to do so.
>>>>
>>>> It now takes 1 min 20 secs for a full build, when it used to compile
>>>> in 13 seconds.
>>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>>
>>>> (building with DSSS and tango)
>>>>
>>>> --bb
>>>>
>>>
>>> I generally make all my imports private and run a command line tool that
>>> strips unnecessary imports once in a while to minimize intermodular
>>> dependencies. Maybe it could help in your case, too?
>>
>> When programming in Java, Eclipse knows to handle all of this for you.
>> it will suggest adding missing imports, it can remove unused imports
>> and it can convert a foo.bar.* into a list of the specific modules you
>> actually used in the code.
>> I wish that kind of tool would be available for D. Is this
>> functionality implemented in descent? if not, is it planned?
>>
>> I do realize that it's more difficult to do this for D than it is for
>> Java, because of Conditional compilation and other issues already
>> mentioned in this thread. But it would be awesome if I could just write:
>>
>> Stdout("whatever").newline;
>>
>> and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list
>> of imports.
>>
>> --Yigal
>
> You should watch Descent videos on youtube, it is *much* smarter that that!
>
> http://www.youtube.com/user/asterite

I watched the video.
the functionality is that if you write: new Foo; it added automatically an import for Foo. that's very cool and all but I was asking for something more than that.

for Java, Eclipse can add and manage imports for you not only when you do new Somthing() but also for functions - like recognizing that Stdout("string") needs to import tango.io.Stdout. More over, if you wrote some of the imports yourself, or edited some code and removed the only call to some function, you can ask eclipse to orginize your imports and it'll remove unneeded imports and expand Java's Foo.* kind of import to a list of the actual modules the code needs.

Descent is a great project and I want to thank all the developers involved in this great undertaking. All I'm saying is that it would be nice to also have an "organize imports" function in Descent.

-- Yigal

Yigal Chripun wrote:

> Denis Koroskin wrote:
>> On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100@gmail.com> wrote:
>>
>>> Denis Koroskin wrote:
>>>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com> wrote:
>>>>
>>>>> For me, V1.038 compiles my code but takes a really really really long time to do so.
>>>>>
>>>>> It now takes 1 min 20 secs for a full build, when it used to compile
>>>>> in 13 seconds.
>>>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>>>
>>>>> (building with DSSS and tango)
>>>>>
>>>>> --bb
>>>>>
>>>>
>>>> I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?
>>>
>>> When programming in Java, Eclipse knows to handle all of this for you.
>>> it will suggest adding missing imports, it can remove unused imports
>>> and it can convert a foo.bar.* into a list of the specific modules you
>>> actually used in the code.
>>> I wish that kind of tool would be available for D. Is this
>>> functionality implemented in descent? if not, is it planned?
>>>
>>> I do realize that it's more difficult to do this for D than it is for Java, because of Conditional compilation and other issues already mentioned in this thread. But it would be awesome if I could just write:
>>>
>>> Stdout("whatever").newline;
>>>
>>> and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list
>>> of imports.
>>>
>>> --Yigal
>>
>> You should watch Descent videos on youtube, it is *much* smarter that that!
>>
>> http://www.youtube.com/user/asterite
> 
> I watched the video.
> the functionality is that if you write: new Foo; it added automatically
> an import for Foo. that's very cool and all but I was asking for
> something more than that.
> 
> for Java, Eclipse can add and manage imports for you not only when you do new Somthing() but also for functions - like recognizing that Stdout("string") needs to import tango.io.Stdout. More over, if you wrote some of the imports yourself, or edited some code and removed the only call to some function, you can ask eclipse to orginize your imports and it'll remove unneeded imports and expand Java's Foo.* kind of import to a list of the actual modules the code needs.
> 
> Descent is a great project and I want to thank all the developers involved in this great undertaking. All I'm saying is that it would be nice to also have an "organize imports" function in Descent.

And you know for certain that it doesn't have this?

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango