Mark,

I have had a chance to work on this today, but may not tomorrow. Because of 
my long term investment in the tiddlywiki platform, both personally and 
professionally I want to ensure I identify the limitations and ways to 
overcome them.

When building a custom search I saw the performance issue return in 
different circumstances, however the current demo seems to be OK.

Oddly the Wiki is larger than before - perhaps because the noscript section 
is within it. It would be better to replace this with a message that 
Javascript is required.

http://tiddlywiki.psat.com.au/ESPDIC

I have installed and activated the local storage plugin, if you change the 
filter to [all[]] you can work on this in the browser.

Regards
Tony

On Saturday, September 21, 2019 at 11:46:54 AM UTC+10, Mark S. wrote:
>
> 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 tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/4669f0be-1c00-4ef3-8b00-f757390e5672%40googlegroups.com.

Reply via email to