performance improvements by cazacugmihai · Pull Request #53 · yomorun/hashids-java

cazacugmihai · 2018-02-21T18:52:40Z

This change is

0x3333 · 2018-02-21T19:11:35Z

Could you fix formatting, otherwise it's impossible to analyze the diff with so many changes. Thanks.

0x3333 · 2018-02-21T19:12:08Z

Also, if you could explain the performance improvements would help.

cazacugmihai · 2018-02-21T20:46:19Z

I have fixed the formatting.

The performance consists in:

using operations directly to the char arrays instead of using String;
some operations (like computing the validChars, guardsRegExp, sepsRegExp, regexp pattern) are precomputed and cached;
usage of StringBuilder instead of operating with strings (see StringBuilder buffer, ret_strB, StringBuilder hash , etc.);
adding a helper class (CharUtils) for working with char arrays.

cazacugmihai · 2018-02-21T20:50:51Z

src/main/java/org/hashids/Hashids.java

    for (final long number : numbers) {
      if (number < 0) {
-        return "";
+        return ""; // we must throw an exception here (like the case when we compare with MAX_NUMBER)


We must throw an exception here.

*See review notice.

cazacugmihai · 2018-02-21T20:56:16Z

About the performance: I have gained about 100-200 ms for running all the tests (it is at least 20% more efficient).

0x3333 · 2018-02-21T22:14:18Z

Great, I'll take some time to review and get back to you. Thanks.

- used array of primitives instead of Objects (see List<Long> ret)

cazacugmihai · 2018-02-22T14:09:48Z

src/main/java/org/hashids/Hashids.java

-    for (int k = 0; k < arr.length; k++) {
-      arr[k] = ret.get(k);
-    }
+    // TODO remove this comment


Please remove these comments before merging the code (it it is the case).

0x3333

Well, after starting reviewing, don't get me wrong, I stopped after so many misunderstandings.

Overall, some changes are welcome, like DEFAULT_* parameters, validateAlphabet method(Except for exceptions), WORD_PATTERN, usage of char[] instead String, etc, but the fact that we adhere to the original JS implementation(https://github.com/ivanakimov/hashids.js/blob/master/lib/hashids.js) will invalidate the changes.

There is a reason we don't thrown an exception in so many cases, like unique alphabet, no numbers on encode, etc. This is because we must have the same behavior of the original implementation. I really would love to add a more "java-ish" implementation, but I believe that the behavior must follow the default expected by the user.

Well, another issue is that this PR is HUGE, we should break things in small changes, so we can review. So many changes are difficult to track the change.

0x3333 · 2018-02-28T14:19:49Z

pom.xml

      <url>https://github.com/TheConstructor</url>
    </contributor>
+    <contributor>
+      <name>Mihai CAZACU</name>


No caps please.1

0x3333 · 2018-02-28T14:19:56Z

src/main/java/org/hashids/CharUtils.java

+import static java.lang.System.arraycopy;
+import static java.util.Arrays.copyOf;
+
+public final class CharUtils {


Remove the public modifier.

Why? Is an utility class (like Math, Arrays, etc.).

Because this name crashes with several CharUtils out there, this is a helper class for hashids, not broad use.

0x3333 · 2018-02-28T14:23:41Z

src/main/java/org/hashids/Hashids.java


  public Hashids(String salt, int minHashLength) {
-    this(salt, minHashLength, DEFAULT_ALPHABET);
+    this((salt == null) ? null : salt.toCharArray(), minHashLength, DEFAULT_ALPHABET);


This check(salt==null) should not be done here, as all the constructors are calling the same constructor, the check should be done only in the last one in the chain. I liked the idea of DEFAULT_*

The last constructor must not accept null values. It has no sense. More than that, throwing an error by assert salt != null it alerts the user about an invalid argument. A salt can be empty but not null. Null can mean that there is something wrong with your application. Also, it is widely recommended to not use null when you code.

What I meant is that the check can be done only in one constructor, as those other constructors are for default parameters.

Also, assertions are removed at runtime unless you explicitly specify to "enable assertions".

The last constructor takes an array of chars (char[] as 1st param) so I have to do here that check (salt == null).

0x3333 · 2018-02-28T14:24:22Z

src/main/java/org/hashids/Hashids.java


  public Hashids(String salt) {
-    this(salt, 0);
+    this(salt, DEFAULT_MIN_HASH_LENGTH);


You can call this(salt, DEFAULT_MIN_HASH_LENGTH, DEFAULT_ALPHABET); directly, no need to call a intermediate constructor.

Yes, but that's why we have there a constructor with fewer arguments. The JVM will make the optimizations while we keep the code clean/small.

We can have the constructor with fewer arguments, you just don't need to call an intermediate constructor for the sake of simplicity.

In this case there is no optimization to be done, you call the first constructor and the VM will call the second, the third etc.

0x3333 · 2018-02-28T14:29:33Z

src/main/java/org/hashids/Hashids.java

+    this((salt == null) ? null : salt.toCharArray(),
+        minHashLength,
+        (alphabet == null) ? null : alphabet.toCharArray());
+  }


I believe that the private constructor could be removed. Leave the public Hashids(String salt... constructor as the "main" one and the checks remain on it.

The main role of the private constructor is to work with char arrays: char[] salt and char[] alphabet. Following your purpose it will lead to new variables: saltAsChars and alphabetAsChars (or something like that) which will uglify the code.

What I meant is to make the convertion(toCharArray) in only one place, the "last" constructor.

0x3333 · 2018-02-28T15:03:28Z

src/main/java/org/hashids/Hashids.java

-    alphabet = alphabet.replaceAll("\\s+", "");
-    seps = seps.replaceAll("\\s+", "");
-    seps = Hashids.consistentShuffle(seps, this.salt);
+    seps = Hashids.consistentShuffle(seps, salt);


always prefix methods/attributes with this..

Why? This is not a JAVA rule. Perhaps a JS one. Please check any class implementation of JDK.

0x3333 · 2018-02-28T15:05:19Z

src/main/java/org/hashids/Hashids.java

    }

-    return this._decode(hash, this.alphabet);
+    return _decode(hash, alphabet);


always prefix methods/attributes with this.

Why? This is not a JAVA rule. Perhaps a JS one. Please check any class implementation of JDK.

0x3333 · 2018-02-28T15:06:00Z

src/main/java/org/hashids/Hashids.java

   *
-   * @param hash
-   *          the encoded string
+   * @param hash the encoded string


Respect the new line after paramater name.

Why? This is not a JAVA rule. Perhaps a JS one. Please check any class implementation of JDK.

0x3333 · 2018-02-28T15:06:40Z

src/main/java/org/hashids/Hashids.java

-          num %= (last.charAt(0) + i);
-          sepsIndex = (int) (num % this.seps.length());
+          num %= last.charAt(0) + i;
+          sepsIndex = (int) (num % seps.length);


always prefix methods/attributes with this.

Why? This is not a JAVA rule. Perhaps a JS one.

0x3333 · 2018-02-28T15:06:49Z

src/main/java/org/hashids/Hashids.java

-      if (ret_str.length() < this.minHashLength) {
-        guardIndex = (numberHashInt + (ret_str.charAt(2))) % this.guards.length();
-        guard = this.guards.charAt((int) guardIndex);
+      if (ret_strB.length() < minHashLength) {


always prefix methods/attributes with this.

Why? This is not a JAVA rule. Perhaps a JS one. Please check any class implementation of JDK.

This is not a java rule, this is our convention rule, all call to instance members are prefixed with this. Read our code.

It is pretty hard to add your contribution to the community if every project has its standards. This is why there are Java code conventions (by Sun, Oracle, Google - which are quite similar).

You are just not getting it. Why making the code a mess, if you can follow just simple rules? It's not hard to make your code look like the same as everybody else.
They are quite similar, but the are different, plain simple.

Don't get me wrong, I'd love to merge your contribution, but it is not in a way to be merged. As I said in another issue report, this project has a long history, we just can't change it and deploy, several people are using it. What we can do is work on a new major version, looking to integrate better with java idiom, faster performance, etc.

cazacugmihai · 2018-02-28T17:18:48Z

About breaking this pull request in smaller pieces: I can't do this because the most part of it is related to the migration from String to char[]. I may extract the constants and the validation method but it will not help much reviewing the code (because those changes are only a couple of lines).

0x3333 · 2018-02-28T18:32:20Z

pom.xml

+      <artifactId>jmh-generator-annprocess</artifactId>
+      <version>1.9</version>
+      <scope>test</scope>
+    </dependency>


Why did you add this dependency?

My mistake. I have run a benchmark to check the performance. Thanks for seeing it! :)

0x3333 · 2018-02-28T19:08:32Z

@cazacugmihai what do you think about creating a branch and work on a new version? @gabrielhora you are invited to this discussion.
I'll create an issue to work on that.

cazacugmihai · 2018-02-28T19:38:48Z

Sure, I can do that.

0x3333 · 2018-02-28T19:44:54Z

Issue 55 - V2 Proposal. Let's discuss there before starting to code.

performance improvements

e282be6

fixed formatting

d134613

cazacugmihai commented Feb 21, 2018

View reviewed changes

- more usage of System.arraycopy

7d4e3ca

- used array of primitives instead of Objects (see List<Long> ret)

cazacugmihai commented Feb 22, 2018

View reviewed changes

cazacugmihai added 4 commits February 22, 2018 16:11

used copyOf instead of copyOfRange

b1a1a4c

revert

84af659

fixed returned version

9d1e7b3

used copyOf instead of copyOfRange

803995d

cazacugmihai mentioned this pull request Feb 24, 2018

Should we throw an exception for negative numbers as well? #54

Closed

0x3333 requested changes Feb 28, 2018

View reviewed changes

fixed the check for finding the duplicates in the alphabet

0585d3e

0x3333 reviewed Feb 28, 2018

View reviewed changes

cazacugmihai added 3 commits February 28, 2018 20:36

cleaned up the pom.xmml

38439b9

removed assertions

d095999

CharUtils has now a package scope

9d7901c

cazacugmihai mentioned this pull request Feb 28, 2018

V2 Proposal #55

Open

3 tasks

Conversation

cazacugmihai commented Feb 21, 2018 • edited by fanweixiao Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

0x3333 commented Feb 21, 2018

Uh oh!

0x3333 commented Feb 21, 2018

Uh oh!

cazacugmihai commented Feb 21, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cazacugmihai commented Feb 21, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

0x3333 commented Feb 21, 2018

Uh oh!

cazacugmihai Feb 22, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0x3333 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cazacugmihai Feb 28, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cazacugmihai Feb 28, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cazacugmihai Feb 28, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cazacugmihai commented Feb 21, 2018 •

edited by fanweixiao

Loading

cazacugmihai commented Feb 21, 2018 •

edited

Loading

cazacugmihai Feb 22, 2018 •

edited

Loading

cazacugmihai Feb 28, 2018 •

edited

Loading

cazacugmihai Feb 28, 2018 •

edited

Loading

cazacugmihai Feb 28, 2018 •

edited

Loading

cazacugmihai Feb 28, 2018 •

edited

Loading