On which note, would anyone object if we disabled benchmark compilation by
default when building the BE tests? I mean separating out -notests into
-notests and -build_benchmarks (the latter false by default).

I don't mind if the benchmarks bitrot as a result, because we don't run
them regularly or pay attention to their output except when developing a
feature. Of course, maybe an 'exhaustive' run should build the benchmarks
as well just to keep us honest, but I'd be happy if 95% of Jenkins builds
didn't bother.

On 20 February 2017 at 19:18, Jim Apple <[email protected]> wrote:

> https://issues.cloudera.org/browse/IMPALA-3784
>
> I'd prefer it removed from git if it is removed from CMakeLists.txt,
> but I'm OK with either that or removing the unrolling.
>
> Also, as a reminder, "-notests" skips building the tests.
>
> On Mon, Feb 20, 2017 at 7:12 PM, Todd Lipcon <[email protected]> wrote:
> > Hi all,
> >
> > I've noticed that status-benchmark.cc takes 8+ minutes to compile on my
> dev
> > box. It seems this is due to use of macro expansions to unroll a loop
> 1000x
> > for the benchmarks.
> >
> > Whether that's actually a useful benchmark that reflects real-life usage
> of
> > Status, I'm not sure. But I'd wager that no one is looking at the results
> > of this benchmark on a regular basis, and maybe we could remove or
> disable
> > it for a normal build?
> >
> > Any objections to a patch which either disables the unrolling (subject to
> > an #ifdef that could be easily re-enabled) or removes the benchmark from
> > CMakeLists.txt (also easy to re-enable)? This is by far the long pole in
> my
> > compilation.
> >
> > -Todd
> > --
> > Todd Lipcon
> > Software Engineer, Cloudera
>



-- 
Henry Robinson
Software Engineer
Cloudera
415-994-6679

Reply via email to