Could making all tasks use one event handler speed up responding to events or displaying many tasks?

[claremacrae]

Description

A very useful message on Discord

I was playing around with rendering a lot of items in obsidian (albeit with Dataview), and I seem to remember one of the sources of a slowdown was adding event listeners to every single element. I took a quick look at the tasks source and it seems every task has a checkbox with an event listener on it ... that might be one of the root causes? The version I implemented adds only one event handler, and then gathers the necessary data from data attributes on the dom node. Might be worth looking at. Feel free to ping me if you want to have a conversation around it 🙂

For reference, here is the tasks event handler: https://github.com/obsidian-tasks-group/obsidian-tasks/blob/7716c2894fd721e6de5691066647822b3c7a1bad/src/Task.ts#L483 and as an example, here is the one I implemented: https://gist.github.com/johanfriis/468cc06326fec23c70dc4a3127874461#file-view-js-L71

Required Steps

No response

How to Test

No response

[BluBloos]

the performance issue for rendering many tasks may be what has already been mentioned.

but it may also be this:

the toLi function calls the Obsidian API call of MarkdownRenderer.renderMarkdown.

to render a single task it takes roughly 2ms...

[claremacrae]

Yes the calling tree will have changed, but here is what I had in July 2022:

I see that, at least when it was first released, Obsidian-Tasks-Calendar did not call MarkdownRenderer.renderMarkdown() - and it drew tasks massively quicker...

All of which pushes in the opposite direction from the theme ability work being done in Tasks currently.

An Aside:

I have some notes on actions to improve performance, not all of which are in GitHub (at the time, I was the only person working on Tasks, having only just taken it over, and was doing a lot of stuff in parallel....)

Now I am in the happy position that several people are contributing to tasks, which is great. Unfortunately I am still doing a lot of stuff in parallel 🤣

The two biggest improvements in performance are likely to be:

• Find a way to cache the last results of a Query (QueryCache?) so that renderers never redraw existing results if there would be no visible change
• Figure out how to render long task lists incrementally as the user scrolls (paging..)

[BluBloos]

Sorry if this comment looks like I am ignoring your most recent comment, but I have found some info on some slowness here.

I took a trace where I marked a task as done from within the query renderer.

It appears that toLi is called individually for each task in the list. It actually seems like some low-hanging fruit here to batch up the list render calls to the very slow markdown renderer. I haven't tested but I suspect that batching work and making a single call to the markdown renderer will make things much, much faster.

[claremacrae]

Oh wow, that sounds really very positive.

[FeralFlora]

Looking forward to when the potential performance improvements mentioned here are implemented, because in certain scenarios with broad queries, Tasks becomes impractical to use.

Edit: Using limit is a nice workaround in the meantime 👍