On 7/25/14, 12:13 PM, "Alan Conway" <acon...@redhat.com> wrote:
>On Fri, 2014-07-25 at 16:47 +0100, Fraser Adams wrote: >> >> On 25/07/14 15:30, Alan Conway wrote: >> > On Thu, 2014-07-24 at 17:31 +0100, Fraser Adams wrote: >> >> On 24/07/14 13:59, Alan Conway wrote: >> >>> Very important point I forgot to mention: are you doing a release >> >>> build? >> >>> >> >>> cmake -DCMAKE_BUILD_TYPE=Release >> >>> >> >>> That makes a big difference. It enables optimization flags for the >>C++ >> >>> compiler. The default is not optimized. >> >>> >> >> Alan, >> >> I've mentioned this before, but I remain unconvinced that the >>default >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> should be for an unoptimised build. I totally realise that seems to >>be >> >> "the CMake way", but it always used to be the case under automake >>that >> >> the default was something reasonably optimised. >> >> >> >> If it turns out that your suggestion is indeed the cause of the >> >> discrepancy I think that would back up the view that *at the very >>least* >> >> the documentation for doing the build should mention this and if >>there >> >> is still a general view to default to the unoptimised I actually >>think >> >> that the CMake for qpid and proton should display a warning to remind >> >> users that they are using an unoptimised build. >> > I agree (not sure why I didn't before, probably not paying attention.) >> > The default actually isn't any of the advertised build types (Debug, >> > Release etc.) it's a "just ignore opt/debug flags" build which is not >> > especially useful for anything. I never use it. >> > >> > So I vote for making the default build type Release. Someone who finds >> > performance sucks is more likely to leave without asking questions >>than >> > someone who has trouble with their debugger (and since the default >> > doesn't set -g anyway that doesn't appear to be a problem.) >> > >> > Any counter opinions? (as always, I assume silence is consent :) >> > >> > Cheers, >> > Alan. >> > >> > >> Thanks for this discussion Alan! >> >> My vote would be to default to the most optimised/operational-quality >> build possible. My reasoning being that I suspect that *most* people >>(if >> not all) coming in fresh would have a not unreasonable expectation that >> qpid would "just work" and moreover would "just work" at its best. Your >> "leave without asking questions" point is something that as a community >> I believe that we must have high on our list of things to avoid! >> >> If the RelWithDebInfo is exactly as fast then that's probably OK, but >>if >> I'm honest I believe that the default should really be to build >> something that a user might want to ship in an operational >> mission-critical system and I'm not personally keen on the idea of >> shipping with debug symbols or anything else that could potentially >> increase an attack vector. >> >> I'm more than happy that we supply documentation that tells users how >>to >> enable debugging etc. but all of that is really developer focussed IMHO >> and I think that the default should be first and foremost user focussed. > >I'm inclined to agree that the default should be user focused rather >than developer focused. On the gcc/intel/RHEL6 system I benchmarked >Release is slightly better but not much. However I can't say if that's >the case for other compiler/OS/hardware combinations. Assuming its >implemented correctly one would assume that Release is going to be the >most release-worthy in general if there is a tradeoff to be made. > >Any further thoughts from the RelWithDebInfo fans? > >Cheers, >Alan. I believe that the person likely to be downloading qpid source is a developer. It is likely a developer that does not want to become intimately familiar with debugging Qpid - they just want it to work without asking questions. But it is a person who may need a sensible stack trace, line numbers, etc. to at least post back here if something goes amiss. They will, after all, need to be testing their own software that uses Qpid and may have occasion to ask things here. When things are all debugged and ready to deploy, the user may want to rebuild w/o debinfo, but if not, it will still perform very well in the field. -Steve --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
