On Mon, 27 Mar 2006, Andrew Lenharth wrote:>> Another option is to build an optimized build with assertions on. Do to >> local demand, I added a build option 'make ENABLE_OPTIMIZED=1 >> ENABLE_ASSERTIONS=1' that provides this. > > How does this compare size and performance wise with a debug build or a > release build?I haven't done any scientific measurements. Here is some educated guessing :) I know that a debug build is about 10x bigger and 10x slower than a release build. Linking also takes about 10x as long with a debug build than it does for a release build. With assertions on, linking takes virtually the same time as a release build, I would expect it to also be about the same speed as a release build: a WAG would be within 10%. For the people that requested the optimized+assertions build, the big issue was link-time. Having a huge link time significantly impacted their productivity and they happened to not care about performance for most development. OTOH, not getting assertions was preventing them from finding bugs. The more I think about it, the more I like a configuration that looks like this: 'llvm --enable-optimized' should always build a release build. LLVM from CVS should always default to a debug build. LLVM releases should default to 'release + assertions'. Thoughts? -Chris -- http://nondot.org/sabre/ http://llvm.org/
I think using different settings is generally (and this this case too) a bad idea because it makes things more complicated. All developers know how to build LLVM. Most (new/casual) users expect a certain behaviour and they will judge LLVM on subjective grounds. If linking/performance suffers they will continue looking for whatever gives them that extra bit of performance. People like me that take the time to file bugreport are willing to invest time in LLVM and are most probably also willing to recompile a full-debug LLVM. New users you want provide the best possible feeling, existing users / developers should type the additional option. (hmm, are does that sound too much like Apple's philosophy) :) >>> Eric On Mar 27, 2006, at 9:09 PM, Chris Lattner wrote:> On Mon, 27 Mar 2006, Andrew Lenharth wrote: >>> Another option is to build an optimized build with assertions >>> on. Do to >>> local demand, I added a build option 'make ENABLE_OPTIMIZED=1 >>> ENABLE_ASSERTIONS=1' that provides this. >> >> How does this compare size and performance wise with a debug build >> or a >> release build? > > I haven't done any scientific measurements. Here is some educated > guessing :) > > I know that a debug build is about 10x bigger and 10x slower than a > release build. Linking also takes about 10x as long with a debug > build than it does for a release build. > > With assertions on, linking takes virtually the same time as a > release build, I would expect it to also be about the same speed as > a release build: a WAG would be within 10%. > > For the people that requested the optimized+assertions build, the > big issue was link-time. Having a huge link time significantly > impacted their productivity and they happened to not care about > performance for most development. OTOH, not getting assertions was > preventing them from finding bugs. > > The more I think about it, the more I like a configuration that > looks like this: > > 'llvm --enable-optimized' should always build a release build. > > LLVM from CVS should always default to a debug build. > > LLVM releases should default to 'release + assertions'. > > Thoughts? > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Mon, 27 Mar 2006, Eric van Riet Paap wrote:> I think using different settings is generally (and this this case too) a bad > idea because it makes things more complicated. All developers know how to > build LLVM. Most (new/casual) users expect a certain behaviour and they will > judge LLVM on subjective grounds. If linking/performance suffers they will > continue looking for whatever gives them that extra bit of performance. > People like me that take the time to file bugreport are willing to invest > time in LLVM and are most probably also willing to recompile a full-debug > LLVM.I agree, but there is a balance here: Users almost ALWAYS use releases. Developers almost ALWAYS use CVS. Also, developers configure a lot more often than users ;) -Chris> On Mar 27, 2006, at 9:09 PM, Chris Lattner wrote: > >> On Mon, 27 Mar 2006, Andrew Lenharth wrote: >>>> Another option is to build an optimized build with assertions on. Do to >>>> local demand, I added a build option 'make ENABLE_OPTIMIZED=1 >>>> ENABLE_ASSERTIONS=1' that provides this. >>> >>> How does this compare size and performance wise with a debug build or a >>> release build? >> >> I haven't done any scientific measurements. Here is some educated guessing >> :) >> >> I know that a debug build is about 10x bigger and 10x slower than a release >> build. Linking also takes about 10x as long with a debug build than it >> does for a release build. >> >> With assertions on, linking takes virtually the same time as a release >> build, I would expect it to also be about the same speed as a release >> build: a WAG would be within 10%. >> >> For the people that requested the optimized+assertions build, the big issue >> was link-time. Having a huge link time significantly impacted their >> productivity and they happened to not care about performance for most >> development. OTOH, not getting assertions was preventing them from finding >> bugs. >> >> The more I think about it, the more I like a configuration that looks like >> this: >> >> 'llvm --enable-optimized' should always build a release build. >> >> LLVM from CVS should always default to a debug build. >> >> LLVM releases should default to 'release + assertions'. >> >> Thoughts? >> >> -Chris >> >> -- >> http://nondot.org/sabre/ >> http://llvm.org/ >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://nondot.org/sabre/ http://llvm.org/