You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Ameya Sanjay Sanjay Ketkar <ke...@oregonstate.edu> on 2017/06/09 17:50:21 UTC
AutoBoxing overhead in lambda expressions
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
Re: AutoBoxing overhead in lambda expressions
Posted by Nate McCall <zz...@gmail.com>.
Hi Ameya,
Did you end up creating any issues for your findings?
On Mon, Jun 12, 2017 at 6:44 PM, Jeff Jirsa <jj...@gmail.com> wrote:
> 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 <
> ketkara@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: AutoBoxing overhead in lambda expressions
Posted by Jeff Jirsa <jj...@gmail.com>.
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 <
ketkara@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