Whenever we talk about performance, I always make the point that it is
important to base analysis on careful measurements of performance in the field,
and not rely entirely on intuition as to bottlenecks and optimisation
strategies.
TiddlyWiki has some basic performance monitoring facilities
Hi Mat,
Playing with it, I'm not sure. :D
Attached is a template for that.
Anyhow, I think limiting the recent tab should be slightly easier than it
currently is.
best -tb
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe
So would that result in faster processing than currently?
If yes, then that's a really quick fix for the tab Recent problem
<:-)
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it,
Hi Mat,
I would actually have recent show only x tiddlers, maybe 30, in two groups:
- first group:* "2017-12-11"*
=> the day of the most recent updated tiddler and other tiddlers updated
the same day
- second group: "*older"*
=> any tiddler not in the first group
best -tb
Thanks everyone for replies. Interesting reads, in deed!
About the Recent list - does this idea make sense:
The list from "24 hours and older" is almost static... and maybe it could
be! Instead of having the whole Recent expensively rendered live with a
listwidget, it is - behind the scenes -
There are several other x.render() functions, but they are not called so
often.
-m
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
On Sunday, December 10, 2017 at 4:59:49 PM UTC+1, Tobias Beer wrote:
>
> In fact, recent should not operate on wikitext, it should be plain js to
> stop this performance drain.
>
The problem of the recent tab / More:Tags / MoreShadows / ... imo is within
element.js
Hi Mat,
As my main wiki grew I disabled a bunch of conditional viewtemplates, or
rather, I added a button to only display/toggle them on demand. That
definitely seemed to speed things up.
Then again, the recent tab becomes quite the slow down after a while, it
really shouldn't.
>
>
In fact,
On Monday, December 4, 2017 at 5:25:23 PM UTC+1, Mat wrote:
>
> What would you (the skilled coders here) say is the main cause of this?
>
We didn't do too much optimization yet. ... It's a very time consuming
process, to find out, where the actual bottlenecks are.
And I'm talking from 24h
In TWC I simply hid things in the sidebar, so there was no need to render
them every screen update. I imaging the same would happen for TW5.
On Thursday, 7 December 2017 04:22:45 UTC+11, @TiddlyTweeter wrote:
>
> I have no idea other than TW5 is pretty complex. AND that if you reduce
> the
I have no idea other than TW5 is pretty complex. AND that if you reduce the
sidebar, especially anything tracking a history, to bare essentials
everything speeds up.
J.
On Monday, 4 December 2017 17:25:23 UTC+1, Mat wrote:
>
> This is really a question way above my head but I'm just curious;
11 matches
Mail list logo
