Compilation process is obviously slower than for a non-optimizing compiler, also for .prg since it's also compiled by C compiler.
Here it should be noted that plain -gc2 built .c files can just be compiled using any C compiler option (ie. without optimization), since it cannot be optimized anyway. [ maybe such optimization can be added to hbmk2, to turn off C compiler optimization in this scenario. But it can be done manually as well, for those who use default <= -gc2 options. ] [ In -gc3 mode the situation is different, but -gc3 isn't very good for app level code in general. ] Anyway for interim / local / developer's build it's fine to use C compiler without optimizations (and maybe with enabled debugging option), and for final build use the "slow", but optimal settings. That's the whole idea of "release" vs "debug" builds. With Harbour/hbmk2 it's quite easy to switch compilers, or toggle optimizations. Brgds, Viktor On 2010 Mar 19, at 18:20, francesco perillo wrote: >> Though at least for live builds used by real users >> IMO it's worth to take the pain of a longer build >> to offer a faster working application. It's a one >> time overhead on developer's side and and permanent >> and noticeable gain on the users' side. > > No problem for a loooooooong one-time compiler build.... but I believe > that also prg compilation is slower... hbmk2 incremental helps a lot > but it is anyway a longer edit-compile-debug cycle.... > _______________________________________________ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
