{"componentChunkName":"component---src-templates-blog-post-js","path":"/reflecting-on-reflection/","result":{"data":{"site":{"siteMetadata":{"title":"Tea & Tech (šŸµ)"}},"markdownRemark":{"id":"c9f6d9b9-7c59-59fc-ac40-c7fcfee2b3bf","excerpt":"The other day I was working on Day 4 of Advent of Code.\nI was pretty delighted with myself for solving this one in a handful of minutes when days 2 and 3 tookā€¦","html":"

The other day I was working on Day 4 of Advent of Code.\nI was pretty delighted with myself for solving this one in a handful of minutes when days 2 and 3 took significantly longer.\nOnce I had my code returning the correct value for all the sample inputs, I went ahead and ran it on the main input.

\n
\n

ā€œElapsed time: 9002.5386 msecsā€

\n
\n

Nine seconds. My computer crunched numbers for 9 whole seconds before it spit out the answer.

\n

I didnā€™t like that. Iā€™ll be the first to admit that Iā€™m no Clojure expert, but my solution wasnā€™t inelegant.

\n
(defn get-digits\n  \"Transforms a string or a number into a list of individual digits\"\n  [number] (map #(Character/digit % 10) (str number)))\n\n(defn valid-number? [number]\n  (let [digits (get-digits number)]\n    (and (not (apply distinct? digits))\n         (apply <= digits))))\n\n(defn part1 [[start end]]\n  (count (filter valid-number? (range start (inc end)))))\n\n(defn -main []\n  (time (println \"Day 04, part 1:\" (part1 [402328 864247]))))
\n

Nice and short! And yet, when run, my computer ground its gears for nine whole seconds (on an Intel i7-8700K, no less).

\n

Well, at least I had access to part 2 of the problem now, and it looks like part 2 needed access to the same range of integers.\nMaybe generating that giant list of integers was adding a lot of time?\nI decided to exclude it from the timing calculations:

\n
(defn part1 [numbers]\n  (count (filter valid-number? numbers)))\n\n(defn -main []\n  (let [[start end] [402328 864247]\n        numbers (range start (inc end))]\n    (time (println \"Day 04, part 1:\" (part1 numbers)))))
\n
\n

ā€œElapsed time: 9057.4244 msecsā€

\n
\n

Wait, itā€™s slower? Butā€¦ oh yeah, itā€™s not actually generating all those numbers at once.\nFrom the range page on clojuredocs.org:

\n
\n

Returns a lazy seq of nums from start (inclusive) to end

\n
\n

Because range is lazy, itā€™s not actually building a list of numbers before we start timing the solution to our problem.

\n

At this point, I was curious to see how much faster it would be to run our code on metal rather than on the JVM, so I compiled the code using the GraalVM native-image tool, and ran it again:

\n
$ ./target/day04\nException in thread "main" java.lang.ClassNotFoundException: java.lang.Character\n        at com.oracle.svm.core.hub.ClassForNameSupport.forName(ClassForNameSupport.java:60)\n        at java.lang.Class.forName(DynamicHub.java:1197)\n        at clojure.lang.RT.classForName(RT.java:2211)\n        at clojure.lang.RT.classForName(RT.java:2220)\n        at advent_2019.day99$get_digits$fn__475.invoke(day99.clj:6)\n        at clojure.core$map$fn__5866.invoke(core.clj:2755)\n        at clojure.lang.LazySeq.sval(LazySeq.java:42)\n        at clojure.lang.LazySeq.seq(LazySeq.java:51)\n        at clojure.lang.RT.seq(RT.java:535)\n        ...
\n

A stack trace?\nAt this point, I knew something in my code was to blame, and I took to the internet to see if I could find a clue.

\n

Many of the search results turning up with Clojure and native-image troubleshooting tips mentioned adding a check for warn-on-reflection, so I thought it would be a good idea to turn on and try to compile my code again.

\n
\n

Reflection warning, advent_2019/day04.clj:6:18 - call to static method digit on java.lang.Character canā€™t be resolved (argument types: unknown, long).

\n
\n

Whoa! Now weā€™re on to something! Apparently my code was relying on reflection to determine function argument types.

\n

But wait a minute ā€” Clojure is dynamically typed. How else are you going to determine types? Is there a way to not rely on reflection in Clojure?

\n

As a matter of fact, there is! It turns out that Clojure supports type hinting, which was news to me! From the official Clojure reference:

\n
\n

Clojure supports the use of type hints to assist the compiler in avoiding reflection in performance-critical areas of code.

\n
\n

Immediately followed by a very helpful example:

\n
(defn len [x]\n  (.length x))\n\n(defn len2 [^String x]\n  (.length x))\n\nuser=> (time (reduce + (map len (repeat 1000000 \"asdf\"))))\n\"Elapsed time: 3007.198 msecs\"\n4000000\nuser=> (time (reduce + (map len2 (repeat 1000000 \"asdf\"))))\n\"Elapsed time: 308.045 msecs\"\n4000000
\n

Wait a minuteā€¦ an order of magnitude faster?? And all I need to do is add some type hints?

\n

Letā€™s refactor our code a little bit:

\n

Before

\n
(defn get-digits\n  \"Transforms a string or a number into a list of individual digits\"\n  [number] (map #(Character/digit % 10) (str number)))
\n

After

\n
(defn get-digit [^Character x] (Character/digit x 10))\n\n(defn get-digits\n  \"Transforms a string or a number into a list of individual digits\"\n  [^Integer number] (map get-digit (str number)))
\n

Having made the change, letā€™s run our code again:

\n
\n

ā€œElapsed time: 517.1315 msecsā€

\n
\n

Holy smokes! From 9.05s down to 0.52s! Thatā€™s over 17x faster!

\n

Turns out that, in this case, the reflection was really expensive. The get-digits function is critical to our solution, and is called thousands of times. By ā€œavoiding reflection in performance-critical areas of our code,ā€ we saw a pretty significant improvement in run time!

\n

Since making this discovery, I have added the following to my project.clj file:

\n
:global-vars {*warn-on-reflection* true}
\n

Now, the compiler (and my REPL of choice as well!) will bark at me every time I make ambiguous typing choices.\nDoing so allowed me to find type ambiguities in my Day 02 and 03 solutions as well!

\n

In the end, with a little type hinting, it turns out my solution wasnā€™t so bad after all šŸ˜Š

\n

ā€¦but we can still make it faster. Stay tuned for next time!

","frontmatter":{"title":"Reflecting on Reflection","date":"December 21, 2019","description":"Learn how to speed up Clojure 17x with this One Weird Trick!"}}},"pageContext":{"slug":"/reflecting-on-reflection/","previous":{"fields":{"slug":"/clojure-on-metal/"},"frontmatter":{"title":"Clojure on Metal","tags":["tech"]}},"next":{"fields":{"slug":"/reducing-runtime-with-reducers/"},"frontmatter":{"title":"Reducing Runtime with Reducers","tags":["tech"]}}}},"staticQueryHashes":["63159454","734670849"]}