commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <>
Subject Re: [lang]
Date Mon, 27 Apr 2015 09:43:55 GMT
I'm all for the O(1), O(n) solution. If we have a good test coverage, we
can work on the readability of the code.
I can merge the feature after we have finished the svn -> git migration.


2015-04-27 11:01 GMT+02:00 Adrian Ber <>:

> Hi Bruno,
> Yes, I will add comments and I will even post on my blog a detailed
> explanation and proof that the algorithm complexities are indeed as I said.
> Thanks,
> Adrian Ber
>      On Monday, 27 April 2015, 11:54, Bruno P. Kinoshita <
>> wrote:
>  Hi Adrian,
> Thanks for bringing the discussion to the mailing list. I believe you
> explained well the existing issue.
> I had a quick look at the code, but didn't really investigate the
> algorithm space and time complexities. Assuming we have the scenario you
> described with O(1) and O(n), my vote is:
> [+1] Performance
> [+0] Simpler code (I'm ok if the majority prefers this one too)
> However I believe @rfalke makes a fair point about the code maintenance.
> So my only requirement for the solution with better performance, would be
> that the code has good tests (simple to read, and with good coverage) and,
> perhaps, some comments to explain what's going on to other developers that
> could have trouble understanding the code.
> All the best
> Bruno
>       From: Adrian Ber <>
>  To: "" <>
>  Sent: Monday, April 27, 2015 8:19 PM
>  Subject:
> Hi everyone,
> As per kinow (Bruno P. Kinoshita) recommendation, I'm writing to this
> mailing list about commons-lang issue
> I created a pull
> request: This generated a
> discussion between two possible solutions for shift operation for arrays.
> I'm proposing a solution in O(n) time complexity and O(1) space
> complexity. On the other hand rfalke is proposing a solution in O(n) time
> complexity and O(n) space complexity, arguing that the first solution, even
> though better from a performance standpoint, could be harder to understand.
> I hope I summarized correctly the discussion so far. What do you think?
> In my opinion, especially taking into account that we're talking about a
> generic library, I'll favor the optimized solution. I doubt that any user
> of the library will complain about the code readability, as long as the
> solution provided works as advertised. As the API is the same in both
> cases, users will consider it a black box and will use it as such. If it
> would been an end-user system and such options would have been affecting
> the overall architecture decisions, then, depending on the performance
> requirements of the system, I'd favor an easier to understand solution.
> Thank you,
> Adrian Ber


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message