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...
* 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
It was added as a separate system tiddler, but that means updating a
lot of filters to add and exclude it as appropriate (as we do with
$:/library/sjcl.js itself)
At the moment, we support JSON files containing an array of tiddlers.
With this change the core will import files containing a single
tiddler. Also adding templates for saving individual tiddlers in JSON
format
I used this test:
console.time();for(var t=0; t<200; t++)
{$tw.wiki.filterTiddlers("[all[tiddlers+shadows]sameday[20170210]]");};c
onsole.timeEnd()
Before this patch, I got speeds of approx 190ms, versus 140ms
afterwards.
Note that the ability to add a cache property like this is only
possible because tiddler objects are immutable.
On my machine, the following test performed on the prerelease improves
from 40ms to 8ms with this patch:
```
var a =
$tw.utils.stringifyList($tw.wiki.allTitles());console.time();$tw.utils.p
arseStringArray(a);console.timeEnd()
```
Back in 7d12d89a0a we added support for
Node.js global `Buffer` object, explicitly exposing it to the module
loader sandbox. The value `{}` was used in the browser, but is now
causing problems with libraries that perform feature detection.
The old code required a space after the colon separating the title
fragment from the text, and didn’t trim the strings. The new code is
more tolerant, by not requiring the space, and trimming the strings.
Fixes#2507
The problem stems from a JavaScript quirk: the fact that
`({“undefined":"Me"})[undefined]` returns “Me”. The quirk is that the
value `undefined` is coerced into the string “undefined” when used as
an index.
In this particular case, the code for `wiki.getTiddler()` was returning
the tiddler with the title `”undefined”` when called with the title set
to the value `undefined`. It happens that the pluginswitcher called
`wiki.getTiddler(undefined)`.
While JavaScript runtime errors include the line number within the
module tiddler where the error occured, syntax errors do not, leaving
the user guessing where the error is hiding. Attempt to remedy this, as
well as the various platforms permit.
As seen in the first pass of #2247, it was previously inadvertently
possible for callers to modify the tiddler object itself by adding and
replacing properties.
Part of the upcoming AWS integration work is a custom build of
TiddlyWiki that can run as an Amazon Lambda function. These tweaks
enable the new build to control the loading of SJCL, the package info,
and any preloaded tiddlers.
Astonishingly, it’s much quicker to use `Object.keys()` to get an array
of key names, and then iterate through that. I’m seeing 25% speed
improvements for an empty tiddler iterator.
Previously, we just read the target file as a block of UTF-8. With this
update, we deserialise the file, allowing us to use file formats like
.tid within the tiddlywiki.files file.
For five minutes I stared at the following code...
if(value != null && typeof value === "object") {
Object.freeze(value);
}
... and at the error message that led me to this code: `Object.freeze called on non-object`
And then I remembered that js treads null as object (http://www.ecma-international.org/ecma-262/5.1/#sec-11.4.3). This means the `typeof === "object"` will not discover null and freeze will throw an error...
So `value != null` will also work when value is undefined.
A hard to find bug ;)
Previous changes since 5.1.7 broke the documented semantics by no
longer returning true when the versions match. It affected the upgrade
process, making it impossible to upgrade to a later pre-release (ie
where the version numbers in the upgrade.html match those in the file
being upgraded).
Also reviewed and updated the calls to checkVersions.
@felixhayashi I think that this effectively reverts the change you
original submitted. Are you OK with it?
Hopefully this will help resolve issues that @xcazin and @pmario have
been having with using the client-server configuration to prepare
translations of the TW5 docs.
Only raise the error if the wiki path is explicitly specified on the
command line, avoiding `tiddlywiki —version` raising an error if the
current directory isn’t a wiki folder.
Fixes#990
Jermolene