Hi there,
I’m relatively new to TW and had a really basic question to ask. I remember seeing elsewhere that a lot of tags in a TW file significantly impacts performance. What is the workaround to this? Should I use filters instead of tags if I were to have a large number of tag-like references to tiddlers? Please could I be pointed to an example where the alternative method is used in place of tags? Thanks.
1 Like
Please link to that info, there must have been a reason. tiddlywiki.com has 343 tags. 268 of them also exist as real tiddlers. It contains about 1400 content tiddlers … Does the site feel slow for you?
TW is optimized, to be used with tags. The most powerful tools exist to be used with tags. That’s why they are used a lot. …
IMO it’s not tags, that make TW slow. It’s filters used with tags in the wrong way. But this only happens if you have something that can be used wrong. … right?
So I think you are “prematurely optimizing” something that doesn’t exist.
- What are you trying to achieve with your wiki?
- Which content should it contain?
- How many tiddlers do you expext in eg: 6 months
If you provide us with that info, we may be able to tell you some of our experiences…
In the meantime
have fun!
mario
I had performance problems with the tag filter with 30k tiddlers. But not with tags themselves. I ended up using the search filter. Then I was able to use 60k tiddlers. As it was explained, the problem ironically came from the tag optimization in the core.
I haven’t heard of anyone having problems with too many tags.
Hi Mark, could you open an issue at GitHub with some links to the discussions?
I don’t know if there is a performance problem with lots of tags or not, but I personally find tags really visually disruptive (they distract me from the content and title of the tiddler, which is what I care about most, and interrupt the visual flow of the story river.) My solution was to only have one tag and to instead put everything I would use a tag for into a field.
What is that one tag? It is “Working.” This tag indicates the tiddler is incomplete or still being worked on. For example, I may have the title and text of the tiddler written, but might be missing important field information. I would mark that tiddler with the tag “Working” to indicate it’s unfinished. The one tag makes it easy to come back and work on the wiki again later. It’s also sensible since the tag is disruptive to me, and I think that having a warning on the top of incomplete tiddlers is helpful.
Examples of how I use fields instead of tags is to do things: classifying the type of tiddler (such as “source,” “passage,” etc.), noting the topic category (if any) of the tiddler (“poem,” “short story,” “latin,” etc.), and tracking the citekey for my bibliography. I may quit doing this, bibliography management is time-consuming, and I’m not sure I need it.
I’m still a new user, so take this with a grain of salt.
I might be the source for the idea that tags slow things down. I have had bad experiences with even relatively small files slowing down.
But to be fair, it is not the tags themselves that cause the slowdown, so much as the complicated list filters I was using years ago in view templates and indexes. One example from a few years ago is this: Gospels Bubbles —
Also note that my problems were years ago, and I understand they have done a lot to optimize tags performance since then.
So, if you heard it from me, don’t take it too seriously. Most people have found tags not to be a problem.
not to contradict pmario, but in the special circumstance that you are using an ios browser or using safari on mac (latest versions as of today) AND you are using section editor/streams you may experience lag when editing a section/stream even with just the normal sidebar recent tiddlers tab open (you can test this with the default tiddlywiki and install streams or section editor)
this is safari/webkit-specific it seems (and seems to involve tags+filters). but while safari desktop users may be a minority, ios users are forced by apple policy to use webkit-based browsers. most users on the forum have historically been desktop non-safari users, so there is a bit of unintentional bias in exposure to this particular issue
workarounds on ios: close the sidebar (i normally autoclose mine, but even keeping it open and just setting it to the “open” tab instead of the “recent” tab helps a lot) and minimise use of other filters that display on screen (i have tabs similar to the sidebar recent tiddlers tab, but i close them in normal use)
workaround on mac: use firefox or chrome instead of safari, or do the same as for ios (close sidebar etc)
It’s not the number of tags, or the filters that are used. Finding the tags and calculating the filters needs about 40 milli-seconds with v5.2.0 (I did some test with an updated wiki.)
What causes the lag here, is the number of “tag-pills” that are created in 1 tiddler. There are 3002 tag-pills drawn in 1 tiddler.
Every tag-pill is constructed from $:/core/ui/TagTemplate which contains 16 lines of wikitext code. It contains a call to the tag-pill-body macro which in sum also has about 16 lines of wikitext.
So in sum to create this tiddler TW has to compute 3002 x 32 lines of wikitext. That’s about 96.000 lines of code that have to be interpreted. On my PC this needs about 1.6 seconds …
With a little bit of tweaking I could bring it down to 1.2 seconds. (There seems to be some unnecessary copy/pasted code 
Interpreting and drawing the whole stuff to the DOM is the process that needs the time here.
(3002 tag-pills create about 9000 DOM elements. Eg: a DIV is 1 DOM-element.)
While finding tags and calculating filters is highly optimized in the core already, drawing tag-pills is not. The code used to create the tag-pills is at least 5 years old and it can’t be cached, as it is at the moment. So the whole work has to be done over and over again atm. …
So there should be some room for improvement with a bit of tinkering.
2 Likes
No worries @pmario. I was just using that old project as an example. I’m not looking to fix it. If I ever find another, older project with fewer tags, no emphasis on tag pills, and longer lag time, I may try to upload it for you to comment on what went wrong with it. But I think that was a fairly early version of TW5, too.
It uses v5.1.11. Even if it is old I think it’s a good example. Users usually don’t care, how many elements are created. … And they shouldn’t. It’s the devs that should try to find ways to “streamline” the UX
I have moved the replies and follow up discussion specific to Streams and Section Editor to a separate topic so as to not derail this one:
1 Like