---
title: optimisations
description: ways rovr optimises its performance
---

`rovr` uses textual, which uses python, which is known for how terrible a performance it gives.
<br/>hence, `rovr` makes use of a couple optimisations to make it perform reasonably well

### queue of length 1

used in `MetadataContainer` and `PreviewContainer`

```mermaid
flowchart TD
    a(receive external thread request) --> b{check for active thread}
    b --> |no thread| c[run thread]
    b --> |thread running| d{queue thread}
    d --> |no threads in queue| e[set thread in queue]
    d --> |thread in queue| f[overwrite thread in queue]
    c --> |thread end| h{check for queue}
    h --> |thread in queue| j[get thread from queue]
    j --> i[clear queue]
    j --> |use thread| c
    h --> |no thread in queue|s
    i --> s(stop)
```

this diagram roughly shows how the mechanism works, with the main thing being an intentional debouncer.

- having a normal queue means that it would take a while for each item in the queue to be run, hence a very noticeable lag.
- however, by having a queue of length 1, and overwriting the queue, it means that the latest added item is considered, and anything in between is ignored, greatly improving performance

### debounced updates

used in `MetadataContainer` and `ProcessBarContainer`

```mermaid
flowchart TD
    a(start heavy process) --> c{do heavy process}
    c --> |process completed|h[force label update]
    h --> s(stop)
    c --> |process running|d{0.25s + previous_updated_time < current_time?}
    d --> |true|e[update label]
    e --> c
    d --> |false|f[skip updating label]
    f --> c
```

this diagram shows how it works

- when doing heavy tasks, like calculating folder size, or deleting folders, the appropriate widgets' labels are update spammed.
- by using a 'debouncer', more time is spent on actually doing the process, than to update the progress of the process

I am certainly not the first person to have discovered this, but it is such a nice mechanism to have
