Recently I visited tiddlytools.com and found that it has serious performance issues (like responsing slow). It consumes memory 2 times more than a normal one:
At first I think it’s because it has too much global macros. After testing by importing all the tiddlers on tiddlytools.com (by dragging the “export” button to an empty wiki), I found that its performance isn’t poor. I wonder what makes tiddlytools suffer from poor performance.
First, you should note that “dragging the export button” doesn’t actually import “all tiddlers”… it doesn’t include any “system” tiddlers (i.e., tiddlers starting with “$:/”), which omits many $:/config/TiddlyTools/... tiddlers that control the behavior of lots of different things.
Second, did you do a save-and-reload? If you didn’t, then the performance difference is likely due to the time-related features set up by a “StartupAction” tiddler, TiddlyTools/Time/Ticker, which is processed once-per-second using an interrupt-driven interval timeout and does the following actions:
write a TWCore system timestamp to $:/temp/time/ticker to trigger TiddlyTools/Time/Clocks display updates.
Because this changes the value of a stored tiddler, it broadcasts a TWCore “refresh” event to all rendered widgets, but that should only update elements that are dependent upon either the value contained in $:/temp/time/ticker or directly use the results of a <<now ...>> macro.
Note that, if the TiddlyTools/Time/Ticker interrupts are NOT occuring, the TiddlyTools/Time/Clocks display still updates whenever the TWCore broadcasts a refresh event triggered by other interactions such as opening/closing a tiddler which changes the $:/Story tiddler contents, or showing/hiding a popup which creates/deletes a $:/state/popup/... tiddler.
invoke <<alarms_tick>> in TiddlyTools/Time/Alarms to trigger alarm processing when an scheduled alarm time is reached
invoke <<autosaver_tick>> in TiddlyTools/Time/AutoSaver to trigger autosave processing when the autosaver countdown reaches 00:00:00
invokes <countdown_tick>> to trigger TiddlyTools/Time/CountDown display updates and countdown processing when a countdown timer reaches 00:00:00
Third, TiddlyTools uses some images that are stored externally (using _canonical_uri references). For example, the default “fishtank” page background image is externalized. I’m certain that your test didn’t include these external images, so the browser didn’t need to render them.
On the other hand… if you DID do a save-and-reload but don’t observe the “poor” performance, then further investigation is needed to determine what is creating the additional processing overhead.
-e
Hope this isn’t too off topic, but I think it relates to performance.
Is there a way to turn off the second-hand on the analog world clocks? I’m sure it’s taking extra render time, and it’s a bit distracting.
My first stab would be refactoring the buttons in the calendar to use $eventcatcher. Then I’d apply a class and kill the repeated style attrs:
Drawing the analog clock second hands doesn’t take any significant “extra render time”. However, I can see how they can be “a bit distracting”.
To that end, I’ve updated the options settings (gear button) in TiddlyTools/Time/WorldClocks to add a checkbox for “[x] hide seconds”. When checked, this causes a variable, tt-clocks-seconds to be set to “hide”.
Then, in TiddlyTools/Time/Clocks, the showhands() macro checks for [<tt-clocks-seconds>!match[hide]] to determine if the analog clock second hand should be displayed.
Update both of these tiddlers to get the new “hide seconds” option.
enjoy,
-e
I’ve spent quite a lot of time optimizing the TiddlyTools Calendar performance.
Keep in mind that displaying a full-year calendar only renders 365 or 366 $button widgets. While there is certainly some overhead for this display, an entire year is displayed in about 1.5 seconds (depending, of course, on how many individual events, timers, alarms, journals, logs, and tiddler changes there are)… and displaying a single-month is even quicker (generally 100-200msec).
Also, I’ve already experimented with using $eventcatcher+divs instead of $buttons. What I found was:
$eventcatcher+divs doesn’t produce any significant savings in rendering performanceSo… while it was a good suggestion… it just doesn’t make any difference to the overall TiddlyTools.com site performance, especially since the Calendar overhead only applies when actually displaying a whole-year calendar.
-e