Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing apache commons & Guava dependency #60

Merged
merged 9 commits into from
Dec 27, 2017
Merged

Removing apache commons & Guava dependency #60

merged 9 commits into from
Dec 27, 2017

Conversation

vishwakarma
Copy link
Member

This commit contains --

  1. removal of apache commons dependency
  2. Writing own LCS since we no longer use apache commons lib.

@LouizFC
Copy link
Collaborator

LouizFC commented Dec 23, 2017

This commit contains:

  1. removal of guava library. Simple methods got inlined, others got moved to PathUtils.
  2. creation of PathUtils:
    It serves as a low level internal api for dealing with low level paths/jsonpointers.
    also I pre-compiled regexes used in decoding, see Tiny optimisations #54

@LouizFC
Copy link
Collaborator

LouizFC commented Dec 24, 2017

Maybe we could further optimize the lcs algorithm. I am gonna take a look at this: https://github.com/fillumina/LCS

@vishwakarma
Copy link
Member Author

Sure @LouizFC
Regarding LCS, i don't think we could do better than O(N*M) but regardless of that I will have a look at the repo link which you shared.

@vishwakarma
Copy link
Member Author

Hi @LouizFC
So far --

  1. All test-suite passed ( one checked-in with this library and other one i have which contains 16M operations)
  2. Earlier to run 16M operation test-suite, it used to take ~6 minutes 30 seconds, now it takes 5 minutes 57 seconds.

class InternalUtils {

static List<JsonNode> toList(ArrayNode input) {
List<JsonNode> toReturn = new ArrayList<JsonNode>();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably initialize with size hint (i.e parameter specifying capacity)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed


private static List<JsonNode> reverse(List<JsonNode> list) {
List<JsonNode> toReturn = new LinkedList<JsonNode>();
for (int i = list.size() - 1; i >= 0; i--) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would probably be better to forward-iterate the list (the interface makes no guarantees about time complexity on indexed retrieval/update) and build up an ArrayList (which does).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use Collections.reverse, which guarantees linear time complexity instead of this method

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That requires a clone first, not sure it'll end up being any faster...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inside InternalUtils.longestCommonSubsequence, we could use Collections.reverse ( it does in-place reversal ) before the return statement.
By your last comment, did you mean that sir?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's possible, but may be slightly less readable. Bottom line, we don't have a benchmark suite yet, so the whole discussion is kind of moot :-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am using @cyber-front test-suite ( shared sometime back with both of us ) for benchmarking where it creates 65,536 random objects and performed a series of 256 updates on each.

/*
* Merging remove & add to move operation
*/
/*
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why multi-line comments? Just makes everything more difficult...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, will make it Single line comment

Preconditions.checkArgument(second.isArray(), "LCS can only work on JSON arrays");

return ListUtils.longestCommonSubsequence(Lists.newArrayList(first), Lists.newArrayList(second));
return InternalUtils.longestCommonSubsequence(InternalUtils.toList((ArrayNode) first), InternalUtils.toList((ArrayNode) second));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Slight change in error semantics, parameters no longer checked for whether or not they are arrays. Intentional?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the caller already checks whether both inputs( source & target) are of Array type before calling this method, i thought to remove the additional checks.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, but I checked and couldn't see the aforementioned check at the caller. Anyway it's only for clarity of errors when the API is misused, so not a critical point regardless.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, caller of compareArray() methods checks the data-type of source & target.

Copy link
Collaborator

@LouizFC LouizFC left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's all good now. We removed the dependencies and gained a little perfomance boost. My only issue was running the tests: I runned all tests, but some were failing in the beggining. I could not find in where in the .json file the test data was. I think adding a little more information when the tests fail (like file name and "message" field) may be beneficial. I can submit a PR for this later if wanted, since junit offers a message in the "assertEquals" method

@@ -147,11 +147,11 @@ public void replace(List<String> path, JsonNode value) {
if (isNullOrEmpty(fieldToReplace) && path.size() == 1)
target = value;
else if (parentNode.isObject())
((ObjectNode) parentNode).put(fieldToReplace, value);
((ObjectNode) parentNode).set(fieldToReplace, value);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the change? Is this semantically equivalent?

Copy link
Collaborator

@LouizFC LouizFC Dec 25, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The old method is long deprecated in jackson api. But yes, the new one is equivalent

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that you commented, this change shouldn't be in this commit, it passed without me noticing, sorry. I will let you decide if this should pass or not

This change got in to this commit without I noticing it. I will roll it back for now and wait for feedback.
@vishwakarma
Copy link
Member Author

@LouizFC
Looks good, Thank you

@vishwakarma vishwakarma merged commit 7973f70 into master Dec 27, 2017
vishwakarma added a commit that referenced this pull request Dec 27, 2017
vishwakarma added a commit that referenced this pull request Dec 27, 2017
* removing apache commons dependency

* Moved getArrayNodeRepresentation to PathUtils. Removed EncodePathFunction

* Removed guava.

*  making 0.3.10-SNAPSHOT -> 0.3.11-SNAPSHOT & making few methods private

* relacing reverse() with colelctions.reverse() and other review comments

* commenting out print statements in tests

* Renamed getArrayNodeRepresentation to getPathRepresentation. Also made Constants final

* Rolled back a api change.

This change got in to this commit without I noticing it. I will roll it back for now and wait for feedback.
@LouizFC
Copy link
Collaborator

LouizFC commented Dec 27, 2017

You are welcome @vishwakarma. Thank you too for letting me take part in this, it was a pleasure. I look forward for helping more in the future, if you want, of course.

@vishwakarma
Copy link
Member Author

@LouizFC , Your are open to propose any change in this project or to even start a new project. I would be available.
How can i connect you over gmail or other social network for future?

@LouizFC
Copy link
Collaborator

LouizFC commented Dec 27, 2017

@vishwakarma I have added my email in to my github profile. Thank you for your interest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants