From a391c1f531d6e8b2c20032bf78b61b3be0574f70 Mon Sep 17 00:00:00 2001 From: pubkey <8926560+pubkey@users.noreply.github.com> Date: Tue, 27 Feb 2024 14:49:10 +0100 Subject: [PATCH] FIX spelling --- docs-src/docs/rx-storage-opfs.md | 2 +- docs-src/docs/rx-storage-performance.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs-src/docs/rx-storage-opfs.md b/docs-src/docs/rx-storage-opfs.md index 3653dec832b..f0bd72a989e 100644 --- a/docs-src/docs/rx-storage-opfs.md +++ b/docs-src/docs/rx-storage-opfs.md @@ -146,7 +146,7 @@ exposeWorkerRxStorage({ ## Setting `usesRxDatabaseInWorker` when a RxDatabase is also used inside of the worker -When you use the OPFS inside of a worker, it will internally use strings to represent operation results. This has the benefit that transfering strings from the worker to the main thread, is way faster compared to complex json objects. The `getRxStorageWorker()` will automatically decode these strings on the main thread so that the data can be used by the RxDatabase. +When you use the OPFS inside of a worker, it will internally use strings to represent operation results. This has the benefit that transferring strings from the worker to the main thread, is way faster compared to complex json objects. The `getRxStorageWorker()` will automatically decode these strings on the main thread so that the data can be used by the RxDatabase. But using a RxDatabase **inside** of your worker can make sense for example when you want to move the [replication](./replication.md) with a server. To enable this, you have to set `usesRxDatabaseInWorker` to `true`: diff --git a/docs-src/docs/rx-storage-performance.md b/docs-src/docs/rx-storage-performance.md index ddaab91f32c..3020558f65f 100644 --- a/docs-src/docs/rx-storage-performance.md +++ b/docs-src/docs/rx-storage-performance.md @@ -12,9 +12,9 @@ Therefore the performance can be completely different depending on where you use ## Persistend vs Semi-Persistend storages -The "normal" storages are always persistend. This means each RxDB write is directly wirtten to disc and all queries run on the disc state. This means a good startup performance because nothing has to be done on startup. +The "normal" storages are always persistend. This means each RxDB write is directly written to disc and all queries run on the disc state. This means a good startup performance because nothing has to be done on startup. -In contrast, semi-persistend storages like [Memory-Synced](./rx-storage-memory-synced.md) and [LokiJS](./rx-storage-lokijs.md) store all data in memory on startup and only save to disc occasionally (or on exit). Therefore it has a very fast read/write performance, but loading all data into memory on the first page load can take longer for big amounts of documents. Also these storages can only be used when all data fits into the memory at least once. In general it is recommened to stay on the persistend storages and only use semi-persitend ones, when you know for sure that the dataset will stay small (less then 2k documents). +In contrast, semi-persistend storages like [Memory-Synced](./rx-storage-memory-synced.md) and [LokiJS](./rx-storage-lokijs.md) store all data in memory on startup and only save to disc occasionally (or on exit). Therefore it has a very fast read/write performance, but loading all data into memory on the first page load can take longer for big amounts of documents. Also these storages can only be used when all data fits into the memory at least once. In general it is recommended to stay on the persistend storages and only use semi-persitend ones, when you know for sure that the dataset will stay small (less then 2k documents). ## Performance comparison @@ -35,7 +35,7 @@ Here the following metrics are measured: ## Browser based Storages Performance Comparison -The performance patterns of the browser based storages are very diverse. The [IndexedDB storage](./rx-storage-indexeddb.md) is recommeneded for mostly all use cases so you should start with that one. Later you can do performance testings and switch to another storage like [OPFS](./rx-storage-opfs.md) or [memory-synced](./rx-storage-memory-synced.md). If you do not want to purchase [RxDB Premium](/premium), you could use the slower [Dexie.js based RxStorage](./rx-storage-dexie.md) instead. +The performance patterns of the browser based storages are very diverse. The [IndexedDB storage](./rx-storage-indexeddb.md) is recommended for mostly all use cases so you should start with that one. Later you can do performance testings and switch to another storage like [OPFS](./rx-storage-opfs.md) or [memory-synced](./rx-storage-memory-synced.md). If you do not want to purchase [RxDB Premium](/premium), you could use the slower [Dexie.js based RxStorage](./rx-storage-dexie.md) instead.

RxStorage performance - browser