Generally speaking, Patches that decrease boxing/unboxing overhead are great, and we've made a point of committing some of those in the past ( such as in CASSANDRA-12199 and CASSANDRA-8019 ) , though there are also some examples where we've decided not to apply boxing changes to critical code paths that didn't have a meaningful performance impact.
I would expect that if you refactor it in chunks - that is, break it down into a handful of patches, where each patch is contained to a specific subsystem (compaction, commitlog, repair, messaging, etc) so it could be reasonably reviewed - such refactoring would likely be appreciated, especially if it came with quantifiable performance increase (using something like cstar https://github.com/datastax/cstar_perf or stress runs or microbenchmarks or similar). - Jeff On Fri, Jun 9, 2017 at 10:50 AM, Ameya Sanjay Sanjay Ketkar < ketk...@oregonstate.edu> wrote: > Hello, > > I am graduate researcher at Oregon State University, currently studying > lambda expressions in java open source project. > Using a generic Functional interface when a specialized primitive > functional interface can be used, is one the lambda smells I am focussing > on. > for instance Function<Integer, Integer> could be IntUnaryOperator. > > https://github.com/apache/cassandra/pull/116 <https://github.com/apache/ > cassandra/pull/116> > > Is an instance of refactoring, of such lambda smell. > I would love to contribute to this project, by refactoring such lambda > smells. > > I am developing a tool to detect such opportunities. > But all the refactoring done are manual and all instances are checked and > verified by me manually, before creating a pull request. > > Regards, > Ameya Ketkar > > Graduate Research Assistant > Oregon State University
