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 days and not 8h days hours here ;) > Is javascript a slow language per se? > No. ... Not anymore. JS JIT (Just in Time) compilers are at 80%+ native speed at the moment. So that's not the problem. > Is it some fundamental structure of TW? > As soon as we need to "write" to the DOM, it starts to get slower, because modifying DOM elements, can cause a browser internal redraw of the whole page. So as long as we can work with TW internal memory we are ok. ... But at some point we need to hit the DOM. . > Maybe the plentitude of divs in TW? > That's an other problem. ... It's not the DOM structure itself once it is created. Browsers are highly optimized to deal with that. Creating the structure is time consuming. eg: TW wikitext -> gets parsed -> parsetree is created -> parsetree is converted to a widget tree -> widget tree gets rendered to HTML There are some optimizations. eg: widgets can check, if they or their children need to be redrawn. So only parts that are affected by tiddler store changes will be redrawn. The problem now is, that most of the TW UI is created dynamically, which creates unpredictable dependencies. The TW "redraw process" has to check all those dependencies all the time, something happens to the internal tiddler store. > Is it simply that browsers are not made for several MB's of loaded data? > That's not the problem. 1 image of a modern smart-phone has 4+ MByte. Browsers can handle multi MByte well. ... The problem we have is the number of dependencies we have to check. > Have we chosen algos that are less-than-optimal for perfomance but > beneficial for something else? > No. IMO most js algorithms used are performant. But as I wrote, we run them often .... very often :) > Do we use recursions-in-recursions at a very early level in the structure? > Yes, because that's the most efficient way to work with tree structures, like the parse- and widget-tree. > And what makes TWC snappier than TW5? > Almost every UI element is hardcoded and the internal structure is different. TWc UI doesn't react on every tiddler-store change. So it was / is very common, that parts of the UI are not updated, even if they should be. So we basically did trade convenience for speed. have fun! mario -- 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 tiddlywikidev+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywikidev@googlegroups.com. Visit this group at https://groups.google.com/group/tiddlywikidev. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/e3edc51b-1841-4d12-942e-22a5026f7b22%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
