From 2bc68ec94512b0ddf865e8a4eb35c1b08d0bcefb Mon Sep 17 00:00:00 2001 From: Nathan Marz Date: Tue, 6 Sep 2016 09:01:32 -0400 Subject: [PATCH] Updated Specter's inline caching implementation (markdown) --- Specter's-inline-caching-implementation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Specter's-inline-caching-implementation.md b/Specter's-inline-caching-implementation.md index 5b6b2dc..04bb367 100644 --- a/Specter's-inline-caching-implementation.md +++ b/Specter's-inline-caching-implementation.md @@ -40,7 +40,7 @@ With all the ins and outs of doing inline caching now being understood, it turns The goal of inline caching is to do as much work ahead of time so the work to finish compilation at runtime (like parameterizing with local variables) is extremely fast. The prior design reduced the runtime work to a single operation: creating an array and filling it with dynamic params. However, "one runtime operation" is not a hard constraint. It's fine to have more operations as long as they are all fast. -With new new inline caching implementation, the `foo` example from before compiles to this: +The end result of compilation is a single object implementing the `RichNavigator` interface that encapsulates all the navigation done by the path. With new new inline caching implementation, the `foo` example from before compiles to this: ```clojure (defn foo [a data]