All,
I was investigating why it takes such a very long time to create a new tiddler with the inspect feature of Chrome. I was surprised to see the Violation messages shown in the screen shot below. I’ve also included the top ten slowest items. Any ideas on what might be causing these violations? Could they be contributing to the slowness of starting a new tiddler? I’m sure it’s something I’m doing wrong, but I don’t even know where to start. Thanks in advance.
Most of the log messages seem minor, except for a “style refresh” that took 1510.40ms, and a Violation message for “setTimeout handler” which took 2085ms.
At first glance, I was concerned that maybe you are using some of my TiddlyTools timer.html functions, which uses my $action-setTimeout widget.
However, the console log message indicates that this Violation occured in $:/core/modules/wiki.js on line 162, which is in a function named enqueueTiddlerEvent that appears to be part of the TWCore refresh event handling and is described in the code comments as:
“Causes a tiddler to be marked as changed, incrementing the change count, and triggers event handlers.
This method should be called after the changes it describes have been made to the wiki.tiddlers[] array.”
The exact line in this function involved is a call to $tw.utils.nextTick(...).
I don’t have anything more to report at this time, but if you post a copy of your TiddlyWiki online somewhere, perhaps I can dig a little further.
-e
Eric,
I can’t put my TW online due to potential copyright issues. However, I could send it to you privately if that works for you.
Do send him it. It is an interesting issue that needs examination to help US.
It is beyond my skill but I can see the issues Eric points to matter.
Just a comment, TT
I definitely plan to. This is an issue beyond me as well.
Just bumping this to the top. I’ve been unable to make any progress solving this issue on my own.
You are using Edit-CompText Demo — a demo of the Edit-CompText plugin for TiddlyWiki5, yes?
Disable that plugin, and re-load your wiki. That test will tell you if its the plugin, or something in your other wiki content.
I am using and will try disabling it tomorrow. I may try that with some other plugins as well. Thanks for the tip. Should have thought of that myself.
So I tried disabling and removing edit-comptext and the results were the same. I also tried removing the side editor and edit auto list plugins with no difference. The violations were always there and creating or editing a tiddler were extremely slow (on the order of a couple of seconds or more).
I should note that the violations occur on inital load of the TW as well. There is only one startup tiddler and it has a couple of external images.
I also tried changing my sidebar tabs to the open tab to minimize anything that my custom tabs might be causing, but that didn’t change the behavior either.
I have not looked for these messages in the past but do you have some debugging or performance indicators set? Could it be an event catcher or message catcher you are experimenting with?
These violations seem to primarily be timing related. So if something is slowing the wiki as a whole may be enough to trigger them. TiddlyWiki performance has being covered many times in the Google Group at least, try seeing if it occurs when the side bar is closed and only a simple tiddler is displayed etc…
Best of luck
Finally, some progress today.
Last night, as I was going to bed, I decided that it was time to work back through my archived versions to see when the issue with the slow editing started. So I started that this morning. I’ve been pretty good about making an archival copy everytime I make structural changes (not necessarily textual changes) as well as documenting what those changes were. I have archived versions going back over a couple of years.
Sure enough, after going through the versions, I found the step where the slow editing started. It runs out that the only difference between the two versions was the deletion of the Font Awesome plugin (http://fa5-free-svg.tiddlyspot.com/). The version with the plugin was fine and the one without was not. After a little digging I discovered that there were some leftovers from the plugin still there (see first screenshot).
Once I deleted these, the slow editing was gone. I still received the “setTimeout” violation on initial load and navigation within the TW, however (see second screenshot). The other violations were gone. I’m not sure what that violation means, but I wouldn’t notice it if I didn’t have the console open.
Thanks for sharing back your result, it may help someone in the future.
Perhaps there was some debug code in there. The name violations suggests to me a threshold was reached, be it withing the browser features or a message sent from the wiki could be determined in the Browser doco, or try another browser with the problem wiki.
Good reminder for all to retain key versions of large evolving and mission critical tiddlywikis.
Interestingly, I tried my file in FireFox and Edge and neither of them showed the “setTimeout” variation. Not sure what that means.
So did you some how fiddle with Chromes dev tools to trigger "violations ", I don’t know if you can only a suspicion.
Not knowingly. I wouldn’t even know how to do that.
That’s just an information, that chrome thinks that there is some code that can be optimized. Chrome thinks, that everything should be done in about 16ms, so a refresh rate of 60Hz can be done. …
In our case we “violate” this rule, if many elements of the UI have to be created. Eg If you open the “All tab” or the “Systems tab” in the right sidebar, where the UI has to “create” many many links.
Usually users don’t care about delayed UI feedback up to 400ms or a bit more if they did click a button. … If The UI stutters without user interaction even a delay of 50ms may be noticeable
So it’s highly depends on the expectation of the user. If I know, that a button click will trigger some heavy calculations 1 second delay won’t be a problem.
If I want to watch a video a 1 second delay while watching the video IS a problem.
Thanks very much @pmario. Very useful insight. I agree, there are some delays that are more tolerable than others. It certainly depends on whether or not that delay is expected or is a surprise. In the case of the delay in editing, that was a surprise and becoming quite annoying.
