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

Performance: Buffer Updates - Investigate & benchmark Piece Table approach #80

Closed
bryphe opened this issue Feb 23, 2019 · 1 comment
Closed
Labels
enhancement New feature or request I-slow User-facing performance issue P-backlog

Comments

@bryphe
Copy link
Member

bryphe commented Feb 23, 2019

We currently have a sub-optimal strategy for handling buffer updates from Neovim. We do a lot of Array splicing which is slow for large buffers. We should start by benchmarking our existing performance characteristics.

In investigating various data structures that we could use to improve this:

The Piece Table is the most appealing to me - it's an immutable data structure, so it's a very natural fit for our language and architecture. We don't necessarily need the undo faculty of it (as we defer that functionality to Neovim) - but we could periodically consolidate the immutable blocks when the application is idle - this would help offset some of the key downsides of the data structure (that it isn't self optimizing, that retrieving a byte involves iterating sequentially over the 'pieces').

@bryphe bryphe changed the title Performance: Investigate 'Piece Table' Performance: Investigate 'Piece Table' and benchmark + improve buffer update perf Feb 23, 2019
@bryphe bryphe changed the title Performance: Investigate 'Piece Table' and benchmark + improve buffer update perf Performance: Buffer Updates - Investigate & benchmark Piece Table approach Feb 23, 2019
@bryphe
Copy link
Member Author

bryphe commented Feb 27, 2019

The piece table should drastically reduce the cost of inserting into large buffers, as most of the cost of our previous strategy is because we incur lots of copying / memory cost in creating new arrays when splicing. Ideally, with the piece table strategy, the cost should be the same when inserting in a large buffer or a small buffer.

In the current state of the world, as measured by #96 , that is not the case:

+----------------------------------------------------------------------------------------------------------------------------------------------+
|  BENCHMARK                                      |  TIME               |  MINOR GC  |  MAJOR GC  |  MINOR ALLOC  |  PROMOTED  |  MAJOR ALLOC  |
|-------------------------------------------------+---------------------+------------+------------+---------------+------------+---------------|
|  Buffer: Add lines to empty buffer              |  1.22300958633      |  334       |  67        |  24359        |  1627      |  100002627    |
|-------------------------------------------------+---------------------+------------+------------+---------------+------------+---------------|
|  Buffer: Insert line in middle of small buffer  |  0.000998497009277  |  1         |  0         |  244029       |  25        |  25           |
|-------------------------------------------------+---------------------+------------+------------+---------------+------------+---------------|
|  Buffer: Insert line in middle of large buffer  |  0.546031951904     |  401       |  80        |  42349        |  3945      |  110005945    |
|-------------------------------------------------+---------------------+------------+------------+---------------+------------+---------------|
|  Buffer: Clear large buffer                     |  0.                 |  1         |  0         |  19029        |  25        |  25           |

@CrossR CrossR added enhancement New feature or request I-slow User-facing performance issue labels Apr 27, 2019
@bryphe bryphe closed this as completed Jul 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request I-slow User-facing performance issue P-backlog
Projects
None yet
Development

No branches or pull requests

2 participants