1
0
mirror of https://github.com/Jermolene/TiddlyWiki5 synced 2024-12-29 11:30:28 +00:00
TiddlyWiki5/editions/tw5.com/tiddlers/workingwithtw/Performance.tid

34 lines
3.2 KiB
Plaintext
Raw Normal View History

2015-03-30 18:28:39 +00:00
created: 20150330155120127
modified: 20191014091943444
2015-03-30 18:28:39 +00:00
tags: [[Working with TiddlyWiki]]
title: Performance
type: text/vnd.tiddlywiki
TiddlyWiki ships with defaults that are designed to get the best out of modern devices from smartphones to desktop computers. If you need to work on older, less powerful devices, or work with large amounts of content, there are a few steps you can take to improve performance.
!! Usage
2015-03-30 18:28:39 +00:00
* ''Avoid the "Recent" tab''. It is computationally slow to generate and update in response to tiddler changes.
2015-04-09 10:01:49 +00:00
* ''Use the "Vanilla" theme''. The default "Snow White" theme includes visual effects like shadows, transparency and blurring that can be slow to render on older devices
2015-03-30 18:28:39 +00:00
* ''Avoid large tiddlers''. Large bitmaps can significantly slow TiddlyWiki's performance. For example, an image taken with a modern smartphone will often be 5MB or more. Use ExternalImages whenever possible
* ''Don't have too many tiddlers open at once''. Every tiddler you have open will require processing to keep it up to date as the store changes (for example, while you type into a draft tiddler). It is particularly easy when using zoomin story view to end up with dozens of tiddlers listed in the ''Open'' tab in the sidebar. Get into the habit of periodically closing all open tiddlers with the <<.icon $:/core/images/close-all-button>> ''close all'' button
!! WikiText
* ''Use the built-in performance instrumentation''. Studying the [[performance instrumentation|Performance Instrumentation]] results can help highlight performance problems
2019-06-09 16:09:35 +00:00
* Take advantage of indexed filter operators. The following constructions at the start of a filter run will be optimised to run many times faster than otherwise:
** `[all[tiddlers]tag[x]...`
** `[all[shadows]tag[x]...`
** `[all[tiddlers+shadows]tag[x]...`
** `[all[shadows+tiddlers]tag[x]...`
** `[all[tiddlers]field:y[x]...`
** `[all[shadows]field:y[x]...`
** `[all[tiddlers+shadows]field:y[x]...`
** `[all[shadows+tiddlers]field:y[x]...`
** Note that the field indexer currently defaults to indexing field values of less than 128 characters; longer values can still be searched for, but no index will be constructed
** Also note that the “field” operator is also used when the operator name is a fieldname, so, for example, `[all[shadows+tiddlers]caption[x]...` is optimised.
* Use the [[throttling|RefreshThrottling]] feature of the RefreshMechanism judiciously
* Keep in mind that ''transcluding separate tiddlers is more performant than heavy use of macros'' and the difference can be significant in some situations. The result of parsing each tiddler is cached and reused the next time if the tiddler has not changed. The same technique cannot be used for macros and they have to be re-parsed every time, as they are not global but local to the widget tree.
** <<.from-version "5.1.23">> Parse trees are now cached for macros that do ''not'' perform any text substitution either via parameters or variables (i.e. `$parameter$` or `$(variable)$`).
* Where possible ''use the SetWidget or VarsWidget with filters instead of the WikifyWidget'' for declaring variables and string concatenation. The performance of the wikify mechanism is relatively poor as there is no opportunity to cache the parse tree or widget tree.