Cool stuff, Rainer. Btw, I've noticed there's a new debugger installed with newer versions of VisualD (mago?). Do I need to set it up to be used in VS over the default one or is it selected by default after installation?
On 10/17/10, Rainer Schuetze <[email protected]> wrote: > Here's a preliminary new version that includes an option on the general > project configuration page to switch to single file compilation: > > http://www.dsource.org/projects/visuald/browser/downloads/VisualD-v0.3.18rc1.exe > > I've used ddmd as a medium sized project for testing. It has more than > 400 files with most modules mutually importing each other. Some remarks: > > - compilation speed is a lot worse, even when compared to what you would > expect from a similar C/C++ project. It takes almost 8 minutes to > compile ddmd on my system with single file compilation, while the > standard compilation takes about 10 seconds. > > - the dependency files written by dmd are so bloated that the check that > selects the files to compile takes almost 20 seconds. This is because > the size of each dependency file is about 700 kB, summing up to 220 MB > to scan for imported files. (I had to do some optimizations and file > operation caching to get the time down from several minutes). > > - I consider the single compilation mode only sensible for a large > collection of modules that have only limited dependencies. > > - probably, compilation speed could be way better if semantic analysis > would only be done on symbols that are actually directly or indirectly > referred to by the modules passed on the command line. This would need a > slight modification of the semantic analysis, but would also put the > promise of independence of lexical order to the test - and would expose > more of the problems you are currently getting. > > This new version also includes some experimental debug/version statement > highlighting, which has not yet been extensively tested. If it causes > too many troubles, it can be disabled on the global property page > Tools->Options->TextEditor->D->Colorizer. > > Rainer > > > dsimcha wrote: >> == Quote from Rainer Schuetze ([email protected])'s article >>> Could it be related to any of these? >>> http://d.puremagic.com/issues/show_bug.cgi?id=190 >>> http://d.puremagic.com/issues/show_bug.cgi?id=3979 >> >> Yep, these look like at least part of the problem. Glad someone else has >> already >> reduced them to sane test cases so I don't have to. Reducing compiler >> bugs that >> only seem to occur in non-trivial, multi-module projects to decent test >> cases is a >> huge PITA. >> >> Anyhow, the project in question is a very messy codebase because it grew >> very >> organically. It's basically a haphazard collection of research prototype >> algorithms for predicting gene expression from DNA sequence, and every >> time I >> think of a new idea, I tend to just put it wherever I can make it fit and >> almost >> never bother with non-trivial refactoring. Therefore, there are cyclic >> imports >> **everywhere**. >> >>> I have that option on my todo list, but didn't implement it so far >>> because I was not aware of any problems with compiling multiple files. >>> I don't know if this is really an option for a larger project, but what >>> you can do is select "Custom Build Tool" for all files in the "Common >>> Properties" setting of the project property dialog and enter your own >>> command line and output file. But be warned: you will not get any >>> automatic dependency detection. >>> As editing the settings for a lot of files might be very annoying, you >>> might want to set it for one file and then edit the project file with a >>> text editor to copy the settings to other files. >>> Rainer >> >> Since build process automation is by far the biggest reason why I use an >> IDE >> instead of a plain old editor, I'd rather just stick with Code::Blocks for >> now. >> Could you please bump this up the todo list, given that building multiple >> files >> simultaneously is buggy in ways that probably aren't going to get fixed >> too soon? >
