# Virtualization Results

Comparisons between different Virtualization methods from:

1. Native
2. content-visibility
3. react-virtual
4. react-window
5. recyclerlistview
6. resembli

Each method has been tested using different kinds of items to be rendered, from:

1. ChatListItem - an item with similar profiled metrics from TMP chat list
2. Full - an item but with event listeners and using popover menu logic
3. Light - a simpler item with no event listener and no complex logic

The results here presented will compare between methods and between item types.

1. Virtualization methods present huge win on TTI metrics
2. Performance-wise all virtualization methods are very similar
3. Comparisons between item types overall demonstrate that the more complex the item is the heavier the toll

## Methods Results

Overall results demonstrate that Virtualization methods present a huge win on TTI metrics and are definitely worth investigating. Second point to notice is that performance-wise all virtualization methods seem to have very similar results.

### FPS

<!-- | | Native | content-visibility | react-virtual | react-window | recylerlistview | resembli |
| ------ | ------ | ------------------ | ------------- | ------------ | --------------- | -------- |
| FPS | | | | | | |
| Max | 57.13 | 56.98 | 56.91 | 8.75 | 8.86 | 57.40 |
| Min | 14.44 | 14.23 | 2.78 | 2.32 | 2.56 | 2.32 |
| Median | 32.22 | 27.66 | 53.40 | 2.97 | 3.27 | 39.60 |
| Mean | 37.20 | 34.88 | 28.04 | 3.25 | 3.56 | 29.81 |
-->


1. Virtualizations methods seems to have worse FPS results overall
2. Perceiving results shows the opposite

> ⚠️ FPS metrics overall don't seem to be compatible with the reality of what is perceived, not even when CDP FPS panel is followed throughout tests. I'd argue that the current way of taking this metric might be erroneous

### Rendering

<!-- | | Native | content-visibility | react-virtual | react-window | recylerlistview | resembli |
| ----------- | ------ | ------------------ | ------------- | ------------ | --------------- | -------- |
| Renders | 1000 | 1000 | 1916 | 1004 | 987 | 934 |
| Duration | 645 | 721 | 6473 | 8315 | 8486 | 6428 |
| FirstRender | 1498 | 1584 | 50 | 125 | 14 | 11 |
-->




1. Virtualization methods have significantly better TTI metrics
2. surprisingly some methods present less rendered items than the amount of actual items (???)
3. Among the virtualization methods `react-virtual` and `resembli` get the advantage on time to render
4. `react-virtual` presents the worse rendering amount by far.

### Processing

<!-- | | Native | content-visibility | react-virtual | react-window | recylerlistview | resembli |
| ------ | ------ | ------------------ | ------------- | ------------ | --------------- | -------- |
| Memory | 181665 | 180048 | 174282 | 190067 | 192736 | 193363 |
| CPU | 21.75 | 21.75 | 30.25 | 48.75 | 50.25 | 42.00 |
| CPU % | 1.56 | 1.59 | 1.80 | 1.76 | 1.72 | 1.79 |

-->



1. Virtualization methods use more memory
2. Virtualization methods use more CPU
3. All virtualization methods present similar memory usage
4. All virtualization methods present similar CPU usage

### Whitespace Amount (checkerboarding)

Although metrics were taken, they were so dissonant from perceived results it's not even worth presenting.

| | Native | content-visibility | react-virtual | react-window | recylerlistview | resembli |
| ----------------- | ------ | ------------------ | ------------- | ------------ | --------------- | -------- |
| Whitespace amount | 🐌🐌 | 🐌🐌 | 🐌🐌 | 🐌🐌🐌 | 🐌🐌🐌 | ✅ |

Checkerboarding is a big signal of Asynchronous scrolling performances being implemented by the browser engines.
Things to keep in mind is that those results are perceived for a large list of items, and although resembli manages to completely remove checkerboarding,
it comes with a cost of disabling Asynchronous scrolling performance, which might not be ideal for low end devices

## Items results

### native Results

Overall results indicate complete different values as expected by what is perceived. By what is perceived, it's clearly noticeable that the heavier the item is the slow the scrolling is and more checkerboarding is presented.

1. FPS remains the same no matter the complexity of the item
* 
2. First rendering is actually faster on heavier items
* 
3. Memory usage doesn't vary much
* 
4. CPU usage doubles on `chat-list-item`
* 
5. The only expected result would be duration, which is smaller on lighter items
* 

### content-visibility Results

Overall results indicate complete different values as expected by what is perceived. By what is perceived, it's clearly noticeable that the heavier the item is the slow the scrolling is and more checkerboarding is presented.

1. FPS remains the same no matter the complexity of the item
* 
2. Surprisingly First render is heavier on the FULL scenario, but still lighter on LIGHT
* 
3. Memory usage doesn't vary much
* 
4. CPU usage doesn't vary much (and it's actually smaller on heavier items).
* 
5. The only expected result would be duration, which is smaller on lighter items
* 

### react-virtual Results

Overall results confirm what is perceived. The lighter the item the better the result

1. FPS is actually a good metric in this case, the lighter the item the higher the FPS
* 
2. The lighter the item the quicker it is the duration
* 
3. First Rendering is as expected, heavy on heavier items
* 
4. Memory usage doesn't vary much
* 
5. CPU usage varies a bit, going as expected. The lighter the item the smaller the CPU usage
* 
6. ❓Render calls skyrocket the lighter the item
* 

### react-window Results

Overall results confirm what is perceived. The lighter the item the better the result

1. FPS is actually a good metric in this case, the lighter the item the higher the FPS
* 
2. ❓Render calls skyrocket the lighter the item
* 
3. The lighter the item the quicker it is the duration (although still quite high)
* 
4. First Rendering is as expected, heavy on heavier items
* 
5. Memory is a bit heavier on `ChatListItem` and almost the same on the rest
* 
6. CPU usage varies a bit, going as expected. The lighter the item the smaller the CPU usage
* 

### recyclerlistview Results

Overall results confirm what is perceived. The lighter the item the better the result

1. FPS is somewhat a good metric in this case, pointing slow performance on `ChatListItem` and high performance on both simpler cases
* 
2. ❓Render calls skyrocket the lighter the item
* 
3. The lighter the item the quicker it is the duration (although still quite high)
* 
4. First Rendering is as expected, heavy on heavier items
* 
5. Memory is a bit heavier on `ChatListItem` and almost the same on the rest
* 
6. CPU usage varies a bit, going as expected. The lighter the item the smaller the CPU usage
* 

### resembli Results

Overall results confirm what is perceived. The lighter the item the better the result (⚠️ although in some metrics the opposite is true)

1. FPS is a good metric in this case, the heavier the item the slower the metric
* 
2. ❓Render calls skyrocket the lighter the item
* 
3. The lighter the item the quicker it is the duration
* 
4. ⚠️ First rendering is weird...
* 
5. Memory is a good metric as it shows that the heavier the item the bigger the usage
* 
6. CPU usage varies a bit, going as expected. The lighter the item the smaller the CPU usage
* 

###### tags: `virtualization`

# Virtualization Observable Findings

As described by the blog post [Scrolling on the web: A primer - By Nolan Lawson](https://blogs.windows.com/msedgedev/2017/03/08/scrolling-on-the-web/), scrolling on the web is an old and complex problem, involving not only different scenarios:

1. User scrolls with two fingers on a touch pad
2. User scrolls with one finger on a touch screen
3. User scrolls with a mouse wheel on a physical mouse
4. User clicks the sidebar and drags it up and down
5. User presses up, down, PageUp, PageDown, or spacebar keys on a keyboard

But also problems related to:

1. Global document or window - listeners
2. The size of the DOM tree being rendered
3. The size and complexity of the React tree being resolved

After the batteries of tests verified in this experiment, the perceivable conclusions for the different virtualization methods comes to similar conclusions from the results presented by numbers:

1. Virtualization methods provide huge TTI wins
2. All virtualization present very similar results
3. The lighter the items complexity while scrolling the better the results

### ⚠️ APZ and Resembli

Modern browsers have developed a mechanism known as APZ (on Edge, Asynchronous Panning & Zooming) to reduce main thread impact of scrolling and zooming, this is also known as asynchronous scrolling. One of the biggest side effects verified by such mechanism are the checkerboarding, so named because of the way it originally appeared on Safari for iOS (as gray-and-white checkers). In most modern browsers, it manifests as a blank space that appears when you’ve scrolled faster than the browser can paint. This isn’t perfect, but it’s a worthy tradeoff compared to blocked, jerky, or unresponsive scrolling.

[Resembli](https://www.react-virtualized-window.com/list), provides a mechanism that cancels APZ mechanisms. Although that might sound ideal to prevent checkerboarding, the presence of checkerboarding is an expected side effect for asynchronous optimization on scrolling by browsers and is desirable.

### When & How should I use virtualization methods?

It's undesirable to use virtualization solutions prematurely, both perceivable and metric results indicates that non virtualization (both native and `content-visibility`) are performant on small lists. The batteries of tests demonstrate that even with complex items non virtualization achieved good perceivable results on lists with about 100 elements, and about 500 elements with light complexity items.

> It's undesirable to use virtualization solutions prematurely.

There's no magic number for when you should start using virtualization solutions, it may vary depending on a plethora of different reasons, but a good rule of thumbs is complexity of items + amount. A good moment to start using virtualization solutions would be when a significant impact is perceived on Time to Interaction.

> A good moment to start using virtualization solutions would be when a significant impact is perceived on Time to Interaction.

As prescribed on [Scrolling on the web: A primer - By Nolan Lawson](https://blogs.windows.com/msedgedev/2017/03/08/scrolling-on-the-web/), it’s best to avoid attaching wheel or touch listeners to the global document or window objects, and instead add them to smaller scrollable elements. Developers should also use passive event listeners whenever possible, with feature detection to avoid compatibility issues. Using Pointer Events and “scroll” listeners are also surefire ways to prevent unintentional scroll-blocking.

> it’s best to avoid attaching wheel or touch listeners to the global document or window objects

Results (both metric and observable) indicates that the simpler the items included on the list, better the results, no matter virtualization libraries decision. Worst case scenario, if having a simple item is not viable, some mechanism for simplifying the items meanwhile scrolling might be interesting.

> the simpler the items included on the list, better the results