Independent filetree buffer + partial tree rendering by wagoodman · Pull Request #18 · wagoodman/dive (original) (raw)

This was a dozy. Essentially pprof was indicating that too much time was spend writing large strings to the gocui view buffer. This makes sense: when any event occurs (e.g. cursor up, down, collapse, etc) we render a filetree string and write the entire tree to the buffer.

One considered fix was to cache all written lines so when a simple action occurs (such as a cursor move) we are only updating that those two lines (instead of writing the entire tree). Unfortunately, gocui doesn't have a buffer seek or line update methods to use, so that approach was ditched.

Instead filetree.String was adapted into filetree.StringBetween to only generate a string of nodes between two DFS-ordered indexes in this tree. This implied that a non-recursive approach to generating a tree, which makes the code more verbose but easier to reason about what will happen next.

A side effect of this was that the gocui buffer would not be utilized. That is, if I write a string to the buffer that is larger than the screen dimensions, then a scrolling mechanism is provided for a user to view more of the string buffer. However, now that we are essentially only rendering a strings large enough to fit on the screen (instead of the whole tree) it no longer made sense to use gocui's scrolling capabilities (i.e. SetOrigin).

So... this PR implements a new filetree buffer that:

• generates a portion of a tree string (only what can be seen on the screen given the terminal dimensions)
• takes over scrolling from gocui (keeps track of an indepentent view index)

What does this buy us? Now when viewing a very large tree the view is much more performant (before this, it was quite laggy)