# Hashing Method Cache IDs

**URL:** <https://discourse.julialang.org/t/hashing-method-cache-ids/94239>\
**Category:** Internals & Design\
**Tags:** compilation, precompilation\
**Created:** [February 7, 2023, 11:22pm UTC](https://discourse.julialang.org/t/hashing-method-cache-ids/94239 "2023-02-07T23:22:58Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![mrufsvold](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mrufsvold/32/31600_2.png) [@mrufsvold](https://discourse.julialang.org/u/mrufsvold)\
**Post date:** [February 7, 2023, 11:22pm UTC](https://discourse.julialang.org/t/hashing-method-cache-ids/94239/1 "2023-02-07T23:22:58Z")

</div>

Disclosure at the top, I’m asking a question here that is out of my depth, but I keep thinking about it and would really appreciate the thoughts of smart folks.

A while back, I watched [this Strange Loop Talk on Unison, a distributed programming language](https://www.thestrangeloop.com/2019/unison-a-new-distributed-programming-language.html). Unison’s “thing” is that it identifies functions, not by their name but, by the hash of their AST representation. So if you define two functions with the exact same args and body, it will only compile one, and functions that call either of them will actually point to the same function after compilation. It seems to work really well for the problem Unison is trying to solve which is fragmentation across distributed systems.

It got me thinking, could Julia leverage something like this to help with the (pre/re)compilation time problem. My best understanding of the current reason for long recompilation after updates is that the potential for invalidations and the complexity of many packages adding methods and such means you need to run compilation pretty naively since you don’t know if the body of any given function name is the same after an update.

What if the Expr that represents the lowered, inferred version of a specific method call was hashed and then the native code was then cached with that hash as its key. As long as the body of that function is not changed, then future recompilations could skip the native code gen step.

You could go a step further and replace all variable names with v1, v2, … vN before hashing, so renaming variables wouldn’t cause cache misses.

I’m totally expecting to learn that this is a bad idea for very good and obvious reasons, so thank you in advance for your patience.

---

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [February 8, 2023, 4:35am UTC](https://discourse.julialang.org/t/hashing-method-cache-ids/94239/2 "2023-02-08T04:35:53Z")

</div>

As mentioned in [this exchange](https://julialang.slack.com/archives/C674VR0HH/p1674461542532249?thread_ts=1674245762.657489&cid=C674VR0HH), caching of this nature is somewhere on the horizon but it’s not on the schedule. But seeing how long and contentious [that thread](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429) is, maybe its priority will be bumped up 😅

---

<div class="post-metadata">

**Author:** ![mrufsvold](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mrufsvold/32/31600_2.png) [@mrufsvold](https://discourse.julialang.org/u/mrufsvold)\
**Post date:** [February 8, 2023, 11:47am UTC](https://discourse.julialang.org/t/hashing-method-cache-ids/94239/3 "2023-02-08T11:47:15Z")

</div>

> [@uniment](#):
>
> [that thread](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429) is,

Is exactly what prompted me to get off my butt and post this idea! Glad to know it’s already in the conversation. Thanks!

---

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [February 8, 2023, 9:41pm UTC](https://discourse.julialang.org/t/hashing-method-cache-ids/94239/4 "2023-02-08T21:41:52Z")

</div>

Well, it’s in the conversation of making it so simple anonymous functions only have to compile once, not the conversation of improving TTFX. Plus, there aren’t even concrete plans for it so I don’t know that I’d consider it solved. 😅

Having no expertise on the matter, to me it looks like a great idea that should be launched to the top of the priority list.

---

<div class="post-metadata">

**Author:** ![mrufsvold](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mrufsvold/32/31600_2.png) [@mrufsvold](https://discourse.julialang.org/u/mrufsvold)\
**Post date:** [February 8, 2023, 9:48pm UTC](https://discourse.julialang.org/t/hashing-method-cache-ids/94239/5 "2023-02-08T21:48:06Z")

</div>

Fair, if a core dev weighs in on it more precisely, I’ll move “Solution,” but it might be as good as I’ll get for now 🙂