Hi Tony,
That's very interesting. Why should deleting and then re-importing make a
difference? Unless the way I created them bypassed the new optimization
technology.
Maybe @Birthe could try exporting and re-importing her data as well, to see
if her TW performance improves.
I might mention at this point, to add to my chagrin, I was importing these
into the app 6000 at a time. I was using Vim to break up the original word
list into
a manageable dictionary. BUT, unbeknownst to me, Vim was changing
diacritical characters into plain ASCII characters. I didn't even know that
that was
possible. So I have to start over using some other editor (Emacs maybe)
that doesn't savage the data. Each set of imports of tiddlers (conversion
from
a data dict tiddler to tiddlers) was taking 20 minutes or more, with
multiple interruptions to bat the wait dialog out of the way. Ouch
If your method works, it's definitely worthy of a ribbon ;-)
I might not get a chance to work on this until tomorrow.
Thanks!
Mark
On Friday, September 20, 2019 at 6:20:02 PM UTC-7, TonyM wrote:
>
> Ok Mark,
>
> I have something *resembling a solution*. These are the steps I took and
> from this we may draw some conclusions.
>
> *Is there a Tiddlywiki ribbon I get?*
>
> It is a solution and a work around but the root cause is not yet known.
>
> - ESPDIC wiki - exported all tiddlers tagged Vorto to json
> - New Empty Tiddlywiki
> - Imported all tiddlers in above json
> - Searching for the words with the default and advanced search is *very
> fast, none of your reported issues here*
> - Stay away from the side bar recent tab, its too slow
>
> Note: I also cloned the $:/import tiddler into "Word List" after importing
> the words, because it contains a list of all imported words as links to the
> tiddlers. Delete the status field.
>
> Not only does the above work well as is, but I believe rejigging the "Word
> List" into a datatiddler, you could do a custom search inside it and
> provide a link to the resulting tiddler, thus not searching the tiddler
> store for words but searching the wordlist data tiddler.
>
> There may be away to bypass this step by importing the Words as an Info
> plugin, the words will then remain shadow tiddlers unless you overwrite
> them, then a special search that also looks at the shadow tiddlers would be
> required to find words but this should keep the words out of the standard
> search and recent tiddlers tab.
>
> You could also modify the recent sidebar tab to exclude tiddlers tagged
> with Vorto and create a special one for only Vorto items if needed.
>
> Regards
> Tony
>
> On Saturday, September 21, 2019 at 10:49:33 AM UTC+10, TonyM wrote:
>>
>> Mark,
>>
>> I am continuing to research this here is a little of my work product
>>
>> Longer time outs and waiting can be better than multiple continue prompts.
>>
>> I would definitely add a splash screen to this wiki.
>>
>> I can see what you are experiencing but not as severe. By using a
>> taylored search in the only tiddler displayed and the side bar closed I get
>> further improvements. I have not yet set a submit search that only searches
>> once you hit submit.
>>
>> Try this and see if there is a marked improvement or not
>>
>> Vorto/Title/prefix search
>> <$edit-text tiddler="$:/temp/search/title" tag=input/>
>>
>>
>> <$list filter="[{$:/temp/search/title}minlength[3]]">
>>
>>
>> Number found: <$count filter="[tag[Vorto]prefix{$:/temp/search/title}]"/>
>> <br>
>>
>>
>>
>>
>> <details>
>>
>>
>>
>>
>>
>>
>> <$list filter="[tag[Vorto]prefix{$:/temp/search/title}]">
>>
>>
>>
>>
>> </$list>
>> </details>
>> </$list>
>>
>>
>> My hunch is tiddlywiki is rendering something with every keystroke and
>> action that is impacted by the scale of the wiki. Its obvious with a search
>> that changes every key stroke but not before the 3 character limit is
>> reached in my example.
>>
>> I just tried it
>> through a local TiddlyServer and its a little slower but similar.
>> through TiddlyDesktop and its faster but still not easy to use.
>>
>> *Hey could this be it?*
>>
>> *I closed all tiddlers and sidebar and did a firefox developer inspect,
>> to see what is actually presented in this view and possibly damaging
>> performance*
>>
>>
>> - I found a noscript area for when Java script is not available full
>> of static tiddler links (Presumably all tiddlers). I deleted this from
>> the
>> HTML
>> - Then on inspect again I find the div id=storeArea appears to list
>> every tiddler, this may be normal operation however the inspector lists a
>> few pages then says
>> - some nodes were hidden. And a button to Show all 72157 nodes,
>> this is a large number and seems to be twice your 36,000 words.
>> - This looks suspicious.
>>
>> We now need some serious skills to advise.
>>
>> Regards
>> Tony
>>
>> On Saturday, September 21, 2019 at 9:50:04 AM UTC+10, Mark S. wrote:
>>>
>>> Yes, I already have this set to a two minute timeout:
>>>
>>>
>>> https://support.mozilla.org/en-US/kb/warning-unresponsive-script#w_letting-the-script-run-longer
>>>
>>> but of course, that just gets the messages out of the way. You still
>>> have to wait ...
>>>
>>> Thanks!
>>>
>>> On Friday, September 20, 2019 at 4:36:55 PM UTC-7, TonyM wrote:
>>>>
>>>> Birthe,
>>>>
>>>> There are timeouts I commonly increased in browsers to stop this kind
>>>> of error message, at least in earlier versions. I expect they remain in my
>>>> browser settings.
>>>>
>>>> Tiddlywiki does do more than most things in the browser.
>>>>
>>>> Regards
>>>> Tony
>>>>
>>>> On Saturday, September 21, 2019 at 9:15:49 AM UTC+10, Birthe C wrote:
>>>>>
>>>>> Sure enough, Firefox constantly complaining, a webside is slowing, do
>>>>> you want to wait?
>>>>>
>>>>>
>>>>> Birthe
>>>>>
>>>>
--
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/3c7d92ed-58f0-4ebd-ba88-5c67c1918691%40googlegroups.com.
