Permalink
Browse files

Update opt-trace-format.md

  • Loading branch information...
1 parent 4dfd91a commit 9fe0c0e980496a467b47fc11d8e75a229df3cc83 @pgbovine committed Jun 9, 2016
Showing with 17 additions and 18 deletions.
  1. +17 −18 v3/docs/opt-trace-format.md
@@ -585,6 +585,23 @@ subsequent execution point. If we grep for `stdout` in the trace, we see the fol
This isn't rocket science; but just be aware that `stdout` contains the cumulative contents of the stdout
buffer up to that execution point, not only what's been printed by the most recently executed line.
+### Potential stdout optimizations
+
+The default trace format is completely unoptimized. It's designed so as to be "memoryless" -- i.e., a frontend can render an execution state by simply reading that entry and not any of its neighbors.
+
+However, the `stdout` field can often take up A LOT OF SPACE since it's "cumulative" -- i.e., at each step, `stdout` represents the entire contents of the `stdout` buffer, not simply what's been printed out in the current step. Thus, it suffers from N^2 space explosions. Even a simple program like this one prints out an ENORMOUS amount to stdout:
+
+```python
+choices = ['pizza', 'pasta', 'salad', 'nachos']
+for i in enumerate(choices):
+ print choices # if you comment this out, the trace is much smaller
+ choices.append(i)
+```
+
+Thus, this is one target for optimization if deemed necessary down the line. However, I'm hesitant to optimize the trace since it makes trace-handling code in the frontend and backend more complicated :/
+
+One elegant way to optimize is to simply store the completed `stdout` buffer ONCE in the trace. And then within each execution point, store a byte index into the buffer. Thus, to render the stdout contents for each point, all we do is slice the buffer from the start to that index. This is similar to the Unix-y idea of file pointers.
+
## Function Stack Frames
@@ -797,21 +814,3 @@ foo(1)
[TODO: talk about appending `_z` onto `unique_hash` when the frame becomes a zombie.]
[TODO: IMPROVE ME!]
-
-
-# Notes: Potential optimizations
-
-The default trace format is completely unoptimized. It's designed so as to be "memoryless" -- i.e., a frontend can render an execution state by simply reading that entry and not any of its neighbors.
-
-However, the `stdout` field can often take up A LOT OF SPACE since it's "cumulative" -- i.e., at each step, `stdout` represents the entire contents of the `stdout` buffer, not simply what's been printed out in the current step. Thus, it suffers from N^2 space explosions. Even a simple program like this one prints out an ENORMOUS amount to stdout:
-
-```python
-choices = ['pizza', 'pasta', 'salad', 'nachos']
-for i in enumerate(choices):
- print choices # if you comment this out, the trace is much smaller
- choices.append(i)
-```
-
-Thus, this is one target for optimization if deemed necessary down the line. However, I'm hesitant to optimize the trace since it makes trace-handling code in the frontend and backend more complicated :/
-
-(One elegant way to optimize is to simply store the completed `stdout` buffer ONCE in the trace. And then within each execution point, store a byte index into the buffer. Thus, to render the stdout contents for each point, all we do is slice the buffer from the start to that index.)

0 comments on commit 9fe0c0e

Please sign in to comment.