Folks, Great stuff here collaborating to resolve a performance issue.
I hope also to emphasis something I stated early in this thread and in my own example of a high performing version. Tags have a particular ad hoc classification function. One which can be used so many ways, and is great for small wikis, because you can use the same mechanism for many purposes. Of course with lots of different tags the "tag space becomes polluted or messy" It is possible to have multiple tag like fields, see Generic Tags Plugin <http://ooktech.com/jed/ExampleWikis/GenericTagFields/> but just as tiddlywiki already has the type field for its own tiddler types the best way for a designer to handle the example of classifying a large number of tiddlers as words/Vorto is with a field be it containing a tiddler-type value or just an if exist "word" field. Why because it does not use a heavily flexible mechanism for tags to do a simpler job, and in large quantities this makes a difference. Not with standing I have what I consider a good technical and design reason for avoiding tags in this case, it is true that this would not occur to most users/designer. As a result perhaps we can encourage the use of a field such as user-type or object-type which contains a single value from a number of possible values defined by a user. We could even support this by providing a drop down that lets you select from *each value* found in this field anywhere in the wiki (along with edit text to enter new ones). Its about providing a gentle push towards a design pattern that will serve them well. Regards Tony On Thursday, September 26, 2019 at 8:56:16 AM UTC+10, Arlen Beiler wrote: > > I opened an issue on GitHub: > https://github.com/Jermolene/TiddlyWiki5/issues/4275 > > On Wed, Sep 25, 2019 at 6:47 PM Arlen Beiler <[email protected] > <javascript:>> wrote: > >> I've been studying this function for a half hour (yes, sometimes that's >> how I work -- inefficient, I know). Anyway, it suddenly occurred to me that >> >> *if* new position is -1 *then* current position is useless, >> >> - *because* right now *if* new position is -1, *then* it is set to >> current position >> - *immediately after that* it checks *if they are equal* and only >> replaces them *if they are not*. >> >> So if new position was set to -1, then it will be set to current >> position, and therefore is equal to it, and therefore prevents a splice >> from happening. So we could totally optimize this if new position is still >> -1 after the first group of if statements and just exit the function if >> there is nothing to do without looking up the current position. >> >> if(newPos !== -1) { >> var currPos = titles.indexOf(title); >> if(currPos !== -1) { >> titles.splice(currPos, 1); >> if(newPos >= currPos) newPos--; >> titles.splice(newPos, 0, title); >> } >> } >> >> Of course, you still can't use list-before and list-after on 36000 >> tiddlers, but who has ever done that? >> >> On Wed, Sep 25, 2019 at 6:18 PM Arlen Beiler <[email protected] >> <javascript:>> wrote: >> >>> Ok, I found the offending line! And I double-checked that one line using >>> Date.now() and it literally does take six seconds. It varies by about 400 >>> ms from one time to the next, but that's completely accurate! Note that the >>> line is executed many times during the sort and that is the total execution >>> time for that line for one sort operation. >>> >>> [image: Screenshot 2019-09-25 18.02.35.png] >>> >>> On Wed, Sep 25, 2019 at 5:58 PM Arlen Beiler <[email protected] >>> <javascript:>> wrote: >>> >>>> When I step over the line it takes six seconds to show up for the next >>>> line. However, when I run a performance profile of the page and do exactly >>>> one action -- opening the control panel -- it still takes about 6 seconds >>>> but the performance profile shows thousands of refresh calls down the >>>> widget tree one after the next for six seconds. It blames the whole thing >>>> on sortByList, and specifically the replaceItem function inside it, but >>>> I'm >>>> still investigating it. >>>> >>>> On Wed, Sep 25, 2019 at 4:12 PM Jed Carty <[email protected] >>>> <javascript:>> wrote: >>>> >>>>> It is used here: >>>>> >>>>> exports.getTiddlersWithTag = function(tag) { >>>>> // Try to use the indexer >>>>> var self = this, >>>>> tagIndexer = this.getIndexer("TagIndexer"), >>>>> results = tagIndexer && tagIndexer.subIndexers[3].lookup(tag); >>>>> if(!results) { >>>>> // If not available, perform a manual scan >>>>> results = this.getGlobalCache("taglist-" + tag,function() { >>>>> var tagmap = self.getTagMap(); >>>>> return self.sortByList(tagmap[tag],tag); >>>>> }); >>>>> } >>>>> return results; >>>>> }; >>>>> >>>>> which caches the results to make it faster afterward, this works well >>>>> for when a tag isn't on too many tiddlers, but I have no idea what 'too >>>>> many' is here. >>>>> >>>>> I haven't dug too deeply into the cache mechanism and there may be >>>>> some maximum size after which it won't cache results, if that is the case >>>>> than it may have to build the results every time the tag is looked up >>>>> instead of being able to use the cached result. >>>>> >>>>> -- >>>>> 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 [email protected] <javascript:>. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/tiddlywiki/160dda32-67cc-4078-b76a-3e2408239d99%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/tiddlywiki/160dda32-67cc-4078-b76a-3e2408239d99%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/072d5e8a-11c2-4a92-94aa-62f5137d73b4%40googlegroups.com.
