Anyway to improve the speed of TW5?

[Jimmy Liew]

Hi All,
TW5 is slow, some time lagging, when typing and creating new tiddler.  Comparing with TWC, it is fast and the response is fantastic.

Does any scripts running behind it when we typing or creating a new tiddler?

Is there anyway to improve it?

Kindly advise.

[Mark S.]

Just chipping in to say I notice it too. I wonder what is happening in the background to slow down a text box? It will be interesting to find out. My guess is that the developers have very fast machines and so don't sense the lag as much.

You can use a Firefox add-on like "It's all text" to edit the field in a separate editor.

Mark 

[Mal]

You might find this discussion useful.

It might be a good idea to try to make sure you don't have a long list of tiddlers displayed in the sidebar.  Certain selections on the "More" tab seem to cause some of the delays during refresh.  Selecting the "Open" tab might be a good option.

Mal

[BJ]

Hi Guys,
The problem with editing speed has yet to be addressed, if it really is too slow on your machines then you can try the 'editboost' plugin here:
http://bjhacks.tiddlyspot.com/
Its only a temporary hack which cannot be used when running tw5 from node (the bug causing this has been fix so may it will work with node in the near future).

cheers

Jeff

[PMario]

On Thursday, April 3, 2014 4:28:07 AM UTC+2, Jimmy Liew wrote:

Does any scripts running behind it when we typing or creating a new tiddler?

As BJ pointed out, if your right sidebar contains a "short" list, the update will be faster. ... TW5 refreshes the whole display with every keystroke. So the whole sidebar will be handled too. ...

For the upcoming release, Jeremy added some performance measurement features. ... So I think he is already dealing with the issue. I also hope he finds something :)

have fun!
-mario

[Matabele]

Hi

This is also evident if text is being edited in larger tiddlers, or if more than one tiddler is open for editing at any one time. When moving content across from TWC, I had to break larger tiddlers into multiple sections (a couple of screens each) to get adequate performance.

regards

On Thursday, April 3, 2014 4:28:07 AM UTC+2, Jimmy Liew wrote:

[Jimmy Liew]

Hi all,

I really appreciated for all the prompt response.   This google group is cool. :)

PMario, any idea when is the upcoming release for TW5?

[Jeremy Ruston]

Hi Jimmy

There are indeed performance issues with TW5 that I am addressing at the moment.

The underlying issue is that the "refresh mechanism" is a bit suboptimal in the way that it processes filters, to the extent that filter processing can comprise 80% of the refresh cycle time.

BJ's plugin works by deferring the expensive refresh cycle so that it doesn't occur on every keypress. Adding a variant of that mechanism is the "get out of jail card" for these performance issues: we know from BJ's work that it is possible to avoid running the refresh cycle on every keypress.

Best wishes

Jeremy.

--
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+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

--
Jeremy Ruston
mailto:jeremy...@gmail.com

[Jimmy Liew]

Thanks Jeremy,

One question, would it be possible to temporary disable the "Show Preview" feature in the "New Tiddler" screen?  I think the refresh is for the instant preview feature right?


Regards,
Jim

[Jeremy Ruston]

One question, would it be possible to temporary disable the "Show Preview" feature in the "New Tiddler" screen?  I think the refresh is for the instant preview feature right?

Well, the refresh cycle is how all UI updates are handled, and it's the trigger for syncing to the server. As noted above, there is definitely an opportunity to avoid doing it on every keypress, as well as opportunities to optimise the performance of the refresh cycle itself.

Best wishes

Jeremy

[Danielo Rodríguez]

Hi BJ, your link is not working. Could you revise it? I would love to try your hacks.

[jeff wilki]

http://bjhacks.tiddlyspot.com

On 4/4/14, Danielo Rodríguez <rdan...@gmail.com> wrote:
> Hi BJ, your link is not working. Could you revise it? I would love to try
> your hacks.
>

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "TiddlyWiki" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/tiddlywiki/0LIL2f0OyLI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Danielo Rodríguez]

Thank you very much!

Im currently testing your editBoost plugin.

Is there any related issue with non-node implementations? Is it safe to use with a local copy?

thanks!

[BJ]

I only issue is that It is only guaranteed to work with 5.08, as tiddlywiki5 is constantly changing at the moment. Having said that I will update the plugin if necessary with any new release. (as I need to use it myself) .

[Danielo Rodríguez]

Hello BJ your plugin allows some powerful options such editing a Tiddler's own fields or editing tiddler titles. However there are other related problems like the search boxes and the preview panel. Maybe you should include an optional parameter instead of just overwriting the original edit plugin.

Regards

[BJ]

Modification to the edit, and edit-text widget. Added option "onkeyupdate" with values "yes", "no" that set the update event to each key press or once the user move off the entry (yes is the default). Also modified the 'body' template to select onkeyupdate only in preview mode.Modification to the edit, and edit-text widget. Added option "onkeyupdate" with values "yes", "no" that set the update event to each key press or once the user move off the entry (yes is the default). Also modified the 'body' template to select onkeyupdate only in preview mode.Modification to the edit, and edit-text widget. Added option "onkeyupdate" with values "yes", "no" that set the update event to each key press or once the user move off the entry (yes is the default). Also modified the 'body' template to select onkeyupdate only in preview mode.

[Danielo Rodríguez]

That is the present or was already done? Why did you paste it three times?

[BJ]

sorry, I was using my phone and sometime the buttons dont show a click when you press them!

If you look at the edit template you can see that my plugin uses a parameter to switch between "normal" where onkeyupdate is yes (which means the editor saves the text on each key press)  and to the new mode where it only saves when you stop editing. In preview you need to update on each key press to see what your editing will look like. Also I left the search in normal mode as general I expect results without moving the curser out of the edit box.

BJ

[Danielo Rodríguez]

Ok, si it is already implemented.

This is weird because I'm experiencing the opossite. Onkeyupdate seems to be set to no by default.

I'll try it again. Is that documentation extracted from your TW? I don't remember it.

[BJ]

by norml i ment unenhance no is the default