A fundamental question:
Are widgets constantly active, i.e evaluated?
{{{ [[foo]match[foo]] }}}
What about if the tiddler is tagged $:/tags/Global vs not?
Erm. What do you mean by “constantly”?
Could you give an example?
Agreed. I don’t understand the question.
As I understand it (and I could be very wrong, as I don’t understand it well at all, really) the Widget tree is evaluated on startup or on various change events: When there is a change, a root widget asks its children, “Does this change affect you?” They ask their children, and so on, until we know every widget that needs to be updated. Then those ones—and only those ones—are told to re-render themselves. In between such events, the widgets are not evaluated.
Does this help answer the question?
2 Likes
That’s right. The trigger for the TW “refresh” cycle is a change to the TW tiddler store. So every tiddler changed, will trigger an event.
Since every internal UI state in TW is stored in an “$:/state/, $:/temp/ or $:/something/else” tiddler, basically every user interaction triggers a refresh – as it should.
There is a configuration with an exception for text-inputs. They are stored every 400ms by default, to keep the UI responsive for fast changing tiddlers.
Hope that helps
-mario
3 Likes
Thanks guys.
Follow up question; In a TW that is “settled” is there anything that takes up RAM? By “settled” I mean that nobody just press a button, or open a new tiddler with a complex listwidget etc.
Of course. The TW source code itself is in RAM, plus the content of all your tiddlers. There is also the tiddler store, a hash map of tiddler name to the tiddler content. And the parsed widget tree must also be in there, plus all the event handlers being used. I’d be surprised if the main page uses less than 200 MB of RAM.
1 Like
The other answers in this thread are correct but I think it important to understand that once TiddlyWiki is loaded into memory it is in effect idle, awaiting a user interaction (although clocks and timers can be added to tiddlywiki that changes this). Even just selecting a different browser tab may suspend any activity in a tab (Different browsers and settings) and can be paged out to disk.
- This is actualy how most internet pages work as well, and was a similar pattern on mainframe computers in the past.
- The thing is multiple people want access to the same page and come to the server and are sent a page, when input is given (and only then) it is sent back to the server for processing. Which “thinks about it” and sends back the result.
- This supports many more users and the server just responds when needed.
Tiddlywiki specifically
Since tiddlywiki is running in the browser and has Javascript that can run localy, it usualy only goes back to the server to save the file (single file wiki with save rights), however it follows a similar pattern in the browser.
- It sits somewhat idle, and responds when interacted with. What is importiant here is a small change may result in multiple changes through out tiddlywiki, adding a new tiddler may result in it being visible in the story or one or more multiple lists.
- Tiddlywiki is highly optimised to save such changes in Memory, then runs off and updates anywhere this change needs to be reflected on screen, such as updating it in a side bar list (like open tab) but it does not bother updating things you can’t see like another list in a closed tiddler.
- This may help explain how all actions need triggers like a button trigger. The trigger forces tiddlywiki to respond to a change.
- If such an interaction was designed to apply actions to multiple tiddlers it will update the tiddler store in memory, then update anythind displayed.
- Of note, is using a server version, will send changes to the tiddler store back to the server not only memory.
In Summary
- Tiddlywiki allows you to main multiple complex views of the same data one screen at a time, one small change could result in many different parts of your view to be updated. This all happens behind the sceens on your behalf.
- We simply get to enjoy the result but tiddlywiki works hard to update the changes as quickly as possible and return interactivity to the user.
- Ultimatly tiddlywiki does this by “computing the changes” then converting the results to HTML for display in the browser.
- There are various interactions that take place wholey in the browser that make your tiddlywiki appear interactive even when its “engine” is not, like mouse over (using CSS) or an import dialogue after launching open or save.
The original Question: Are widgets active all the time?
In a way they appear to be, but in fact they are “reactivated” after a trigger has occured and if a change needs to be propergated. They are always waiting to respond but only activated when needed either to update the tiddler store or change what you see on screen.
1 Like
RAM usage depends on your browser. I did some measurements using FireFox about:memory
I do have several TWs open at the same time. Some are in hidden tabs, some are “open”
All of them need about 60MB to 90MB ram uns “Explicit Allocations”
I do have about 20 “pinned” and 10-20 active tabs in every browser session. So on my Windows system monitor FF shows 34 instances and uses about 2GByte of memory, with 22 tabs available
I’m using Brave browser. It by default shows memory usage when hovering over each tab, and it says anything between 70 to 270 MB. This is actually what triggered my OP question. I can see that the mere tab in itself requres some RAM but it’s a bit mysterious to me what exactly uses memory in my wikis. Yes, “there are tools” but I haven’t taken the time to look into them…
You can also open the browser dev-tools with F12 and search for the “memory” tab.
The screenshot is site memory actually used. That means the more elements are visible the higher the memory will be, because the DOM is bigger.
Since FF uses about 80MB, there seems to be an overhead of about 20-40MB to manage a site.
I belive one way to imagin it is as the wiki loads into memory, the content we are all familular with, the core and our tiddlers and plugins are loaded into memory. Then as has being documented there are a number of cached title lists that are used to turbo charge filters which may be one example of how tiddlywiki expands in memory to promote performance. I expect those familular with the core can tell us more but I imagin things like system tiddlers containing javascript modules are loaded into memory and “executed” to register various functions etc… this may be seperate from the tiddler itself that contained the “source code”. All this extra memory use is of course discarded once you save the wiki back to the data store and save the tiddlers/wiki back to file, and close the window/tab.