6.2 Performance Evaluation

Performance Evaluation

The purpose of conducting this performance evaluation is to ensure that sashimi-note runs smoothly for the users.

1. UI become unresponsive when rendering large amount of code blocks

Issue

In v0.1.4 Whenever user make changes to the textarea in Editor, the Editor will take the whole string contained inside the textarea and send it to the DocumentPackager > Markdown-it for parsing. Normally, this process should be close to instantaneous (< 100ms).

• However, parsing certain element such as the code block with syntax highlighting is performance intensive. This is a problem as the UI and the Markdown-it parser shared the same thread. When the Markdown. Whenever the parser is busy parsing, it will also hang up the user interface and cause it to become unresponsive.
• Previously, the Editor will send the entire string to the Markdown-it parser on every user's keystroke. This is halt the entire application when user attempted to type consecutively in the Editor.

Improvements

This issue is minimised in version v0.1.5

Throttle

Upon receiving user input, Throttle will allow the input to be stored for a specified amount of time before processing it. This technique significantly reduces the extensive use of markdown processor by sending input in a "chunk" rather than a single character at a time.

An alternative to Throttle is Debounce. The concept of Debounce is similar to that of Throttle in the sense it also stores input for a specified amount of time. The difference for Debounce is that it will detect if there are any additional input after the specified amount of time. If there is, the stored input will not be processed until the additional input have been completed. In terms of performance Debounce may seem to be the better choice as it consolidates all the input before processing it. However if Debounce is used, when typing into sashimi-note's editor, the viewer will not be updated until all the input has been added. This is not very intuitive as there is no direct feedback on the viewer for the user using the editor.

Webworkify

Webworkify is a module that spawns a web worker which acts as a separate independent thread. By using webworkify-webpack for the markdown processor, users will no longer experience delay when typing in the editor as receiving of input and processing of markdown data are now running on separate threads.

2. UI become unresponsive when rendering diagrams

Issue

In v0.1.3 Whenever the Viewer component receive new HTML data, it will call diagramRenderer to re-render all the diagrams found in the Viewer again. One of the diagram rendering API uses mermaidAPI.js. However, as of v0.1.3, mermaidAPI.js will be reinitialised on every re-rendering. This reinitialisation process is performance intensive and unnecessary.

Improvements

This issue is minimised in version v0.1.5

Cache the instance of mermaidAPI.js

Instead of reinitialising mermaidAPI on every re-render process. diagramRenderer is now made into a object instance > DiagramRenderer which will provide 2 separate API, 1 for construction and 1 for rendering. The Viewer component can first construct DiagramRenderer which will initialise and cache a the mermaidAPI instance. Then the subsequent rendering can be called without reinitialising the mermaidAPI.

This result is 3 times performance improvement when drawing mermaid related diagrams.