A few quick observations. Note that I work on a very high end desktop that 
makes it difficult to gauge performance accurately. For example, the second 
Noto document from TT loads in a few seconds for me. However, comparing the 
performance of Streams and Noto might be insightful.

These are averages of 3 runs in Streams and Noto with the tiddly toolmap 

*All top level items collapsed : *
mainRender 4733ms
mainRefresh 1157ms
*All items expanded: *
mainRender 5497ms
mainRefresh 1220ms

*All items collapsed*
mainRender: 222ms
mainRefresh 23ms

*All items expanded:*
mainRender: 2360ms
mainRefresh 184ms

What is interesting here is that Streams is much faster when the items are 
collapsed. Note that streams has a lot of complexity added in the way of 
filter runs for determining collapse state and drag and drag state, so I 
would expect Noto to be as fast if not faster. So are the sub levels in 
Noto rendered even if they are not shown?

Also crucially, the editing experience in Streams seems normal, not any 
slower than with just one tiddler in the stream. Even if the faster 
hardware is masking some of the problem, it shows that Noto is suffering 
far more of a performance hit when editing.

I think it is important to distinguish between rendering performance, when 
first opening the tiddler, versus refresh performance, when typing etc. 

The slow performance in Noto reminds me of what happens when editing forces 
a refresh of the containing tiddler or widget. This could be as simple as a 
set or vars widget that is being refreshed due to a containing tiddler 
being changed, which refreshes all the content inside those widgets. One 
way to resolve this is to rework the logic for filters used to avoid such a 

Another workaround is to edit in draft/temp tiddlers, and only save back to 
the original tiddler when the user actually saves. This would mean that the 
surrounding content would only refresh when you save the tiddler, as 
opposed to on every key stroke. An intermediate step that might offer some 
help is setting the throttle.refresh field on the tiddler being edited.

Note also that somewhere in tiddlytoolmap in one of the list items is the 
code for a filter run, that will end up listing close to all the tiddlers 
in the wiki!! I've removed this in my copy. I wouldn't be surprised if that 
is exacerbating the problem.

I don't have the opportunity to look at the Noto code at the moment, but 
hopefully this might lead you in the right direction with regards to 
performance issues.


You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to