qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
Date Fri, 25 Jul 2014 16:13:32 GMT
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?


To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message