Speed of [[foo]get[title]] vs [{foo!title}]

[[foo]get[title]] vs [{foo!!title}]

Identical output, but is there a difference in speed?

If there is a speed difference, it’d be interesting to get a grasp of its size. (It could be significant in e.g complex filtering or nested lists)

EDIT: My original post asked [[foo]get[title]] vs {{foo!!title}} (i.e the second one was not a filter but a direct transclusion) but @Mohammad 's post here below made me realize my error.

1 Like

The first one actually is a filter! So, it may need a widget or at least filter transclsuion to produce the output.

In Macros and Wikitext scripting I get used to the first notation but for note taking I use the second one {{foo!!title}}. I did not think to performance difference and I like to know how they are compared.

1 Like

Ah, right! I’ve edited the post so to make the comparison fair. Good catch.

1 Like

I think for filters like this one it doesn’t really matter. Filters internally are “compiled” into javascript function calls. I’m pretty sure that the runtime is very similar for those 2 filters.

Even the following comparison would not make a big difference, since internally those 2 transclusions are handled by the same function … a transclusion. It’s only the attributes that are different, where the second one may be a tiny bit more work

{{foo!!title}} and {{{ [[foo]get[title]] }}}

If you open the tiddler-preview and the “widget-tree” setting you will see there isn’t much differences.

1 Like

Thanks Mario! Yeah, that’s what I would guess. I’m fiddling with a thing that takes a frustratingly long time to render so I’m trying to figure out what tweaks are meaningful without compromising the physical output I’m after.

As we found out, very long visible lists that contain links can cause some delay if the output contains thousands ++ …

The problem isn’t the long list, it’s the initialisation of the browser event listeners that make the links clickable, that will need much time.

So if you have very long rendered lists the eventcatcher-widget will probably be an option you should consider. So you can make text-output look like links with CSS but don’t use the link-widget in any way.

Oh, that is interesting to hear! A plugin I’m working on is held back because of this.

This means the titles are really styled buttons, right?

Review Long List with Truncated Previews

@CodaCoder was still using HTML links, but if the event-catcher is handling the functionality, I think you should be to use any element you wish.

Yes, that’s the mechanism I’m talking about. … without the wikify part, because this can slow the whole thing down again. I think a transclusion with custom template for the hovering element would do the trick instead of wikify. … BUT I didn’t play with the code.