The elephant in the room to me is what Ariel said:
>
> What about all the commits that don't intend to have a performance impact
> but do?
On top of that, it's all well and good to microbench the change you make in
a vacuum but what happens when the resource usage implications of that
change
Hi,
I should clarify. Should in the sense of it was fine for the process we
had at the time (ugh!) but it's not what we should do in the future.
Ariel
On Thu, Mar 9, 2017, at 04:55 PM, Ariel Weisberg wrote:
> Hi,
>
> I agree that patch could have used it and it was amenable to
>
Hi,
I agree that patch could have used it and it was amenable to
micro-benchmarking. Just to be pedantic about process which is something
I approve of to the chagrin of so many.
On a completely related note that change also randomly boxes a boolean.
Ariel
On Thu, Mar 9, 2017, at 03:45 PM,
I don't expect everyone to run a 500 node cluster off to the side to test
their patches, but at least some indication that the contributor started
Cassandra on their laptop would be a good sign. The JIRA I referenced was
an optimization around List, Set and Map serialization. Would it really
Hi,
I think there are issues around the availability of hardware sufficient
to demonstrate the performance concerns under test. It's an open source
project without centralized infrastructure. A lot of performance
contributions come from people running C* in production. They are
already running
After looking at the patch, my thoughts (beware, it's getting very
technical):
Original code:
-t = new ListType(elements, isMultiCell);
-ListType t2 = internMap.putIfAbsent(elements, t);
-t = (t2 == null) ? t : t2;
Optimized code:
+t =
Agree. Anything that's meant to increase performance should demonstrate it
actually does that. We have microbench available in recent versions -
writing a new microbenchmark isn't all that onerous. Would be great if we
had perf tests included in the normal testall/dtest workflow for ALL
patches so
