I have turned on Advanced Performance plugin and when I look at the filter stats, it would appear that the worst filter is the one calculating the value of the captions for the guns (152 in total).
So this raises the questions, if my caption field values are calculated, when does this calculation occur, at render time or at load time as well?
If I am reading the stats wrong, how can I link the reported filters to actual code snippets?
At render time — and every time a relevant value changes, thus prompting a rerender. In this case, your complex captions would have to be calculated when you view a list of guns in the TOC, when you open a tiddler containing a list of guns, and when you open a gun tiddler (though this will be a very quick calculation compared to rendering lists of 100+ links with complex captions).
That said, I just opened your wiki and it didn’t seem particularly slow to load or laggy when in use. Are you experiencing noticeable performance issues, or are you simply trying to optimize in advance?
In any case, I think you’re correct that your caption macro is the “heaviest” current aspect of your wiki. If you like, you can try the following revisions, which may be slightly faster:
Note that the second procedure folds the <<known-type>><<unknown-type>> macros into it directly, so you can remove those as well. I also removed the initial <f.TLSisempty GunType> step as it adds no benefit here: it’s functionally the same as the final <%else%> case.
Frankly, I suspect your f.TLSisempty function is overkill for most of the situations in which you seem to be using it — even in the slightly simplified version above. I assume you added it to guard against instances in which a field contains only one or more spaces (and thus is not technically “empty”) — do you foresee this becoming an issue? If not, you can probably replace things like [<f.TLSisempty field-name>match[yes]] with [<currentTiddler>!has[field-name]] and [<f.TLSisempty field-name>!match[yes]] with [<currentTiddler>has[field-name]] in most if not all cases.
Thank you @etardiff your suggestions greatly appreciated.
I am experiencing between 5-10 seconds lag time in loading. It seems to make little difference if I open the Start tiddler instead of the South Australia index tiddler. Firefox developer tools seems to indicate a network issue. However, I am trying to be aware of response times as the wiki develops. This will be most important when we have completed converting all the guns in the register across all states (~250 guns @ 4 tiddlers each, ~2000 images)
I have created a GITHUB account and have uploaded a copy of the wiki to that but when I try and display the wiki, GITHUB responds that it can not display such large files yet.
I am a complete novice with GITHUB. Do you know if there is a simple way of viewing the wiki using a normal browser URL rather than having to be logged in to GITHUB?
The f.isempty code, I am concerned that when editing, the user my leave a field empty. This is especially now that user editing is done via the TW editor rather than my own bespoke editor tiddler wherein I can check for empty values. I did use the has operator earlier on but found that it appeared to not always pick up empty fields. @pmario provided the function code.
That’s a good instinct! I do think it’s a good idea to keep any index tiddlers out of the default startup tiddlers… and you may also want to consider starting on a sidebar tab other than the TOC.
I’m afraid I don’t know much about hosting via GitHub. If you’re looking for a quick/free place to test relative loading speeds, I’d generally recommend TiddlyHost.
The edge case solved by the f.TLSisemptyfunction is specifically fields that contain only one or more spaces — so they may look empty, but aren’t. Otherwise, get[myField] will return only non-empty fields, and has[myField] likewise only returns titles with a non-empty myField (cf. has:field[myField], which will return any tiddler with a field called myField, even if it’s truly empty).
IMO, either of these would probably be generally “good enough”, as they’d only fail if a user entered space(s) but no other text… but if you want to err on the side of safety, you could modify the default TW field editor to include a check/warning for empty fields by modifying the default field template used here:
There may also be a way to change the way the content transcluded is is managed. Perhaps by creating a custom-caption field, which you can use in place of the caption field. Then rather than transclude the content have it coded as a title [[some related title as content]] - [[some related title as content]] when you use/display this content you can choose of the links are active or text.
but also add this field to relinks management, so if you rename the title it will be propagated to all tiddlers containing it.
There are many ways to redesign for performance, and fortunately TiddlyWiki itself helps in the redesign process with tools and custom batches all possible.
