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

Challenge 11.4 unclear advantage of implementation #1141

Open
okomarov opened this issue Oct 2, 2023 · 0 comments
Open

Challenge 11.4 unclear advantage of implementation #1141

okomarov opened this issue Oct 2, 2023 · 0 comments

Comments

@okomarov
Copy link

okomarov commented Oct 2, 2023

The challenge reads:

Our resolver calculates which environment the variable is found in, but it’s still looked up by name in that map. A more efficient environment representation would store local variables in an array and look them up by index.

Extend the resolver to associate a unique index for each local variable declared in a scope. When resolving a variable access, look up both the scope the variable is in and its index and store that. In the interpreter, use that to quickly access a variable by its index instead of using a map.

The changes in the interpreter are:

 public class Interpreter implements Expr.Visitor<Object>, Stmt.Visitor<Void> {
-  final Environment globals = new Environment();
+  final Map<String, Object> globals = new HashMap<>();
-  private Environment environment = globals;
+  private Environment environment;
   private final Map<Expr, Integer> locals = new HashMap<>();
+  private final Map<Expr, Integer> slots = new HashMap<>();

So all scoped environments become an array except globals. However, every time we need to lookup, define or get a variable, we need to get its location from slots. This feels like we swapped a map access from the environment to the locations.

Question

Am I correct in thinking that while we still have the same number of HashMap accesses, the advantage is that the variables are now stored in a contiguous block of memory since the Environment is now an array, and that the efficiency is coming from this change in memory layout rather than not having any HashMap access at all?

In other words, accessing slots is faster than accessing values (old Environment.java code):

private final Map<Expr, Integer> slots = new HashMap<>();

vs

private final Map<String, Object> values = new HashMap<>();
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant