BLITZ support?

[Ptomaine]

The compilation time may be speeded up to 4 times by this approach.

Moreover, BLITZ lets a compiler to see all source code files as a single 'blitz' object and the compiler may optimize it more thoroughly.


What do you think?

[Michael]

The compilation time may be speeded up to 4 times by this approach.

Moreover, BLITZ lets a compiler to see all source code files as a single 'blitz' object and the compiler may optimize it more thoroughly.


What do you think?

Sorry for my ignorance, but what is BLITZ :?? I have searched for it by using Google, but have not found anything relevant.

Thank you.

Michael

[takeshimiya]

I don't know about BLITZ, but there's some technologies in Apple Xcode IDE when using GCC that are just amazing regarding compile speed optimization:

Predictive Compilation
Xcode will even begin compiling a source code file while you are editing it. It begins reading in and parsing headers, making progress compiling the file even before you initiate a build. When you do choose to save and build the file, much of the work has already been compiled.

ZeroLink
Intended for use during development, it lets you bypass the linker, and instead have the executable load the .o files as needed.

Fix and Continue
Lets you make a change to one file, recompile it, and load it into the running executable, WITHOUT quitting, relinking, and relaunching the whole thing.

Distributed builds
Distributes compilation tasks among multiple computers on a network, and takes in account dual processors also.

Question: Do you think, at least in a distant future, that these features will be feasible in Code::Blocks?

[Michael]

I don't know about BLITZ, but there's some technologies in Apple Xcode IDE when using GCC that are just amazing regarding compile speed optimization:

Predictive Compilation
Xcode will even begin compiling a source code file while you are editing it. It begins reading in and parsing headers, making progress compiling the file even before you initiate a build. When you do choose to save and build the file, much of the work has already been compiled.

ZeroLink
Intended for use during development, it lets you bypass the linker, and instead have the executable load the .o files as needed.

Fix and Continue
Lets you make a change to one file, recompile it, and load it into the running executable, WITHOUT quitting, relinking, and relaunching the whole thing.

Distributed builds
Distributes compilation tasks among multiple computers on a network, and takes in account dual processors also.

Question: Do you think, at least in a distant future, that these features will be feasible in Code::Blocks?

Apple Xcode IDE technologies are really interesting and it would be cool if C::B will support them in the future . Anyway, I have a doubt. C::B actually supports several compilers. Therefore to implement such technologies for all the supported compilers would be a huge work. And to implement them just for GCC would probably make C::B users to switch to GCC compiler and neglect the others. As a consequence, it would not make a lot of sense for C::B to maintain several compilers if the users just work with GCC...

Michael

[takeshimiya]

Well, if you worry about that, currently precompiled headers in C::B RC2 are suported for GCC only, and I see lot's of people here using other compilers too.

But nothing stops to implement precompiled headers and the other features for other compilers, in fact I think they will be supported also.

[Michael]

Yes, you are right concerning PCH. But, IMHO I think that doing the same with several technologies at the same time would be more complicate and difficult to mantain later (as the compilers change during the time).

Michael

[takeshimiya]

Well, then the question arises...
What are the future goals of C::B? Being a simple (DevCpp alike) IDE, or being a more full-featured IDE (Xcode, Eclipse, KDevelop alike)?

[Michael]

Well, then the question arises...
What are the future goals of C::B? Being a simple (DevCpp alike) IDE, or being a more full-featured IDE (Xcode, Eclipse, KDevelop alike)?

Yes, right. Soon or later such decisions should be taken. I would prefer for a more full-featured IDE like Eclipse...Anyway, for the moment C::B is IMHO simply doing great.

Michael

[takeshimiya]

Anyway, for the moment C::B is IMHO simply doing great.

We all know that, if not we'll not be here
But Eclipse have some advantages because their community is so big.

I for myself would like to see C::B going mainstream so the entire world isn't just Java|.NET

[sethjackson]

Anyway, for the moment C::B is IMHO simply doing great.

We all know that, if not we'll not be here
But Eclipse have some advantages because their community is so big.

I for myself would like to see C::B going mainstream so the entire world isn't just Java|.NET

Exactly.

[thomas]

Question: Do you think, at least in a distant future, that these features will be feasible in Code::Blocks?

Distributed builds or SMP builds will certainly be implemented, there is no doubt about this.
Predictive Compilation sounds like a nice thing, and it is certainly possible to be implemented. However, running compiles in the background while typing may be a major issue to notebook users or users who own little memory and slow CPUs. A compiler is not really conservative with resources, this has to be taken into account.
ZeroLink is technically certainly possible (at least under Windows I know how to do it, and very likely it is a lot easier under Linux), but this involves some OS-dependent stuff and a good amount of tampering which is not precisely portable.
Fix and Continue is a lot harder to implement. It is still possible of course, but it would involve a lot of things which are outright evil. I would not want it, even for all of its coolness.

[takeshimiya]

Predictive Compilation sounds like a nice thing, and it is certainly possible to be implemented. However, running compiles in the background while typing may be a major issue to notebook users or users who own little memory and slow CPUs. A compiler is not really conservative with resources, this has to be taken into account.

Yes, from Apple User Guide: "On slower machines, enabling predictive compilation may interfere with Xcode performance during editing."

So, all the technologies remarked here are user-selectable of course.

[Michael]

I for myself would like to see C::B going mainstream so the entire world isn't just Java|.NET

Jave and .Net :?? Personally, I do not appreciate too much either Java or .NET. I sympathize much more for C++ .

Michael

[Ptomaine]

Sorry, I didn't explain what the BLITZ was.

First time, where I encountered the BLITZ approach was 'Ultimate++' IDE (http://upp.sourceforge.net).

Briefly speaking, BLITZ creates a single CPP file where several '#include' directives go with the source files and some '#define' directives. Thus the compiler executed ONLY ONCE for compilation but not for every source file.

So, here we go.

[mandrav]

Briefly speaking, BLITZ creates a single CPP file where several '#include' directives go with the source files and some '#define' directives. Thus the compiler executed ONLY ONCE for compilation but not for every source file.

This can be done with every compiler, but I don't see the benefits in doing so. The tiniest change in a source file will need to compile all files again...