What's not good with many viewtemplates?

[Mat]

I've heard cautions against using many viewtemplates, for performance reasons.

But what, specifically, causes the poorer performance from this?

For example, it doesn't make sense that it would be to locate the templates because it is still only one search trough all tiddlers regardless if the filter finds one template or a hundred (...right?)

So is it rather what the viewtemplate shows that can be a problem? E.g if a viewtemplate has a lot of nested lists? ...but in that case, one such viewtemplate could be worse than 10 simpler viewtemplates so it would not warrant caution from using many viewtemplates per se.

Or is the problem if there are many open tiddlers? Beacuse each of them shows all viewtemplates? So it is "N open tiddlers" times "M number of templates". But then the templates only deserves half the blame.

Does the caution change when one uses "conditional viewtemplates", i.e viewtemplates with a wrapping listwidget like

  <list filter="[all[current]tag[foo]]">...</$list> 

?

In summary: What is the actual problem with many viewtemplates?

Thanks!

<:-)

[TW Tones]

Mat,

As is often the case I think it depends on how you implement it. In one solution I built I had a dozen object different object-type tiddlers, and each of these had there own view and edit templates. However the view template only took the current tiddlers object-template field, obtained the object name and added a prefix eg $:/objects/viewTemplates/objectname and transcluded that.

Therefor the bulk of which was used to display the view template was only transcluded on demand.

I saw no performance issues.

Regards

Tones

[Mat]

@Tones, thanks for your thoughts.

> As is often the case I think it depends on how you implement it.

I distinctly recall @Jermolene singling heavy use of templates as a thing that could slow things down so I my interpretation is that they are more critical in this regard than many other things. So, I'm trying to understand what specifically about them that cause this.

<:-)

[Jeremy Ruston]

> As is often the case I think it depends on how you implement it.

I distinctly recall @Jermolene singling heavy use of templates as a thing that could slow things down so I my interpretation is that they are more critical in this regard than many other things. So, I'm trying to understand what specifically about them that cause this.

I’d need more context to be clear about what I meant. Was I talking from the perspective of adding things to the core, or from the perspective of somebody building something out of TiddlyWiki? It sounds like I was talking about adding too many view template segments. The “special” thing about view template segments is that they appear in every tiddler, and so if they take a long time to render the effects will be worse the more tiddlers that are open. Beyond that, it’s all just templates all the way down, and the performance trade-off remains that performance will generally get worse as the templates get more complex.

Best wishes

Jeremy

[PMario]

Hi Mat,

The following image shows, how HelloThere tiddler DOM-structure looks like on tiddlywiki.com with the Recent Sidebar opened. The "higher" the "stacks" are, the more work is to do for the core to create it.

That's 1 reason, why TW tries to only render, what really changed. ...

There you can see, why the "Recent" tab has the potential to slow down the performance. Mainly because it creates more elements as can be shown on the screen. ... And it is redrawn often.

You can also see, that the Tiddler itself is "relatively" flat.

On the top-left there is the "menu-bar" with the "search" input standing out. The sidebar search does a similar thing.

BUT

Making the stacks lower doesn't automatically mean, that the performance is faster. ... Because the elements are cached. ...

I'm sure, there is room for improvements. ... You should have seen an image like this from early alphas, where "transclusions" still did create extra "unused" DOM elements. ...

have fun!

mario

[PMario]

Just to get a feeling: This is my post here at the group. GG also has a nesting level of 24

On the left, there is the "Nav sidebar" ... The last element is my earlier post.

have fun!

mario

[Joshua Fontany]

That's some really cool visualization, nicely done.

Best,
Joshua Fontany

[Mat]

@Jermolene, I'm afraid I can't find exactly when you said it but your reply still answers my question.

@pmario - Haha! Thanks for taking the time with screenshots etc which of course also teaches me (and others) how to use that tool. I'm assuming that the time is measured from the back of the blue and that "double height" means "double time", right? But what does it mean that the, say, search field is slower than everything else? Is the whole page not useable before the search bar is fully loaded? I.e is all frozen?

Thanks!

<:-)

[PMario]

On Monday, May 24, 2021 at 12:13:30 AM UTC+2 joshua....@gmail.com wrote:

That's some really cool visualization, nicely done.

Yea, MS Edge has it built into the dev-tools. 

-m

[PMario]

On Monday, May 24, 2021 at 7:13:04 AM UTC+2 Mat wrote:

@pmario - Haha! Thanks for taking the time with screenshots etc which of course also teaches me (and others) how to use that tool. I'm assuming that the time is measured from the back of the blue and that "double height" means "double time", right?

It's the DOM structure that we see here. So every layer shows a dom element and its child elements. The higher the "bar", the more DOM elements need to be handled. 

Since the TW core has to "calculate" which elements have to be redrawn, it also show a little bit of the "complexity" and the "connections" between the elements. ... BUT it's not directly related to the time that is needed.

But what can be seen in the first image is, that the sidebar calculates more more elements as actually shown on the screen. ...

 

But what does it mean that the, say, search field is slower than everything else?

I think I didn't say that. I only wanted to explain some "landmarks", so you can connect the images to the rendered page. I didn't want to say, that it is slow. ... It probably isn't, since it's only 1 element with several child's. So looping through them should be reasonably fast. 

Is the whole page not useable before the search bar is fully loaded? I.e is all frozen?

As I wrote. The map only shows the dom structure and has no direct relation to the time needed.

-mario