@Mark S: I strongly suspect that any performance issues are not due to sorting/ordering but rather due to the rendering of so many tiddlers. The dynalist plugin should be able to help you deal with that by not rendering anything that isn't in the viewport.
On Wednesday, June 3, 2020 at 7:42:26 PM UTC+2, Mark S. wrote: > > After splitting into your 4000 pieces, how was performance for additional, > normal splits? > > If there's a serious split problem, then the question is, do we: > > 1. Advise people to stick with shorter documents > 2. Use some other mechanism for ordering the tiddlers > > A simple ordering system would be to have a field, "sortby". Then on the > first split you would have > > 001. > 002. > 003. > > and then an additional split at 002. might look like > > 001. > 002.001 > 002.002 > 003. > > and after 002.001. : > > 001. > 002.001 > 002.001.001 > 002.001.002 > 002.002 > 003. > > Obviously this field could get quite long. > > The main reason I didn't pursue this path was because I was thinking about > outlining. For outlining, it needs to be easy to traverse up and down > (actually more "up") a chain of tiddlers. The list filter operators built > into TW allow you to do that. > > I'm assuming that the greater utility of an outliner/editor makes any > performance hit worthwhile, but I guess it will be easier to judge that > when I post the outlner tw. > > I can post it now, but important pieces are unfinished. In particular, > when you split, the new tiddlers aren't assigned a level and fold status, > and so disappear. The interface isn't using standard icons. But if you want > to have a peak: > > https://marxsal.github.io/various/notowritey-outliner.html > > Click on the "hamburg" to change levels. Click on the fold/unfold symbols > to change fold status. > > There's a tool tiddler for converting existing documents into outline > documents (just adds level and fold fields). > > > > > > > On Wednesday, June 3, 2020 at 2:28:44 AM UTC-7, TiddlyTweeter wrote: >> >> TonyM, right, its a design thought. Yeah on a long novel you'd split to >> chapters first then Noto each separately if you were sensible. >> >> TBH, I did not want to distract Mark S. from his thread so feel slightly >> bad posting that. >> >> But I think the performance of list field may be relevant to larger "Noto >> Docs". >> >> Best, TT >> >> On Wednesday, 3 June 2020 11:12:31 UTC+2, TonyM wrote: >>> >>> TT, >>> >>> Understood. >>> >>> I understand the desire for one tool. Perhaps mark could give us a >>> button to split a tiddler using the same mechanism rather than pasting >>> through the front end. >>> >>> However if importing a lot of content, it may be better to divide the >>> incoming material somehow, even if it is mashed together later for reading. >>> >>> An example may be chapters. >>> >>> Sometimes this fragmentation say into chapters actually maintains >>> information about the source that would otherwise be lost. >>> >>> Regards >>> Tony >>> >>> >>> >>> On Wednesday, June 3, 2020 at 7:02:50 PM UTC+10, TiddlyTweeter wrote: >>>> >>>> Actually TonyM the lapse on initial split is not an issue. It didn't >>>> fail. And I'd rather use one tool than two. >>>> >>>> The problem, is the list field performance when its heavily populated?? >>>> After cut, refresh, its still same issue I think. >>>> >>>> Best, TT >>>> >>>> On Wednesday, 3 June 2020 10:56:10 UTC+2, TonyM wrote: >>>>> >>>>> Did you paste into the utility? >>>>> >>>>> Perhaps first loading then processing would be better. Ie you are >>>>> forcing a batch like operation into and interactive one. I expect there >>>>> is >>>>> another way. >>>>> >>>>> Regards >>>>> Tony >>>>> >>>>> On Wednesday, June 3, 2020 at 6:38:42 PM UTC+10, TiddlyTweeter wrote: >>>>>> >>>>>> Ciao Mark >>>>>> >>>>>> *Performance Tests* >>>>>> >>>>>> Test 1 -- Noto instance that can edit 500 short plain text tiddlers >>>>>> (tweet length). Perfectly workable. >>>>>> >>>>>> Test 2 -- Noto instance to slice plain text novel into about 4000 >>>>>> paragraphs. It did manage the slice, though I put the kettle on waiting. >>>>>> Its not really useable for live edit. But IT IS serviceable for initial >>>>>> "document" creation. This is not an NW issue per se but I think a more >>>>>> general issue with *performance at scale of the list field?* As as >>>>>> separate issue I might look at lessons of the e-pub version of TW as it >>>>>> uses dynamic loading well. >>>>>> >>>>>> Side notes >>>>>> TT >>>>>> >>>>>> On Sunday, 31 May 2020 19:28:33 UTC+2, Mark S. wrote: >>>>>>> >>>>>>> In NW, every tiddler split into other tiddlers gets added to the >>>>>>> list field of the main tag. Likewise, every tiddler deleted (via the >>>>>>> interface) is removed from the list field of the main tag. >>>>>>> >>>>>> -- 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/0bbb47dd-39fa-45c5-90da-c1dcb50a557d%40googlegroups.com.
