I noticed that the rendering of a TOC with around 200 entries seemed frustratingly slow.
First, I analysed the execution of the code using the Chrome developer tools "timeline" tab: prepare by switching to the "Tools" tab, then start profiling, switch to the "Contents" tab, and then stop profiling once it has displayed. I then used the "bottom-up" view to dectermine that the various Object.keys() calls in the main wiki store were taking around 500ms of the overall time.
Before making any code changes, I also used TW's built in instrumentation to get some baseline timings: I found that the main refresh cycle was taking around 3.0s when rendering the Contents tab.
I then performed the attached simple optimisations of caching the list of tiddler titles and the list of shadow tiddler titles.
The results bring the overall main refresh time down to about 1.9s, a nearly 50% improvement.
The moral of the story is that the first rule of optimisation is measurement...
* In the interests of performance and expressiveness, switched to using a Sax parser instead of a DOM implementation.
* Use extensible declarative rules to control the slicing process
* Added new optional set of rules for slicing by heading, where the paragraphs underneath a heading are packed into the same tiddler as the heading
* Added a modal dialogue for specifying parameters when slicing in the browser
* House style:
** Spaces after the "!" of titles
** Blank line after titles
** Sentence Case for Heading Text
* Make use of wikitext-example-without-html macro for the examples
* Make use of .tip macro for tip
* Some phrasing improvements and clarifications
* enable doc contributions for dev
fixes#2921
* involves changes to boot.js to properly build OriginalTiddlerPaths on
Windows
* added ContributionBanner
* added Sources tab to info panel
* updated tiddlywiki.info for dev
* normalize path separator to posix for windows
* more generically transform to posix
* extend ListWidget to enforce classes
Previously, the undocumented *class* attribute only allowed to specify
additional classes to be set.
Especially for use within a LinkCatcher, you can now apply / enforce
only the custom classes and avoid any of the defaults being applied
depending on the link target.
This will allow to implement #1161 more gracefully.
* use setClass insted of exclamation mark syntax
update docs & fix typo in docs
* Update chinese translations for revises in #2803
* Revise chinese help texts for "save" and "render" command
* Update chinese help texts for "import" and "load" commands
* Revise chinese help texts for "load" command
