perf: Reduce the impact of 'QueryRenderChild.isFilenameUnique()' on rendering speed

[claremacrae]

Description

In a vault with 6,700 markdown files, I found that the call on QueryRenderChild.isFilenameUnique() for every task that is rendered in search results was taking nearly as long as the actual rendering:

Required Steps

I'm thinking of make Task store TasksFile - and then having all tasks from the same file store the same TasksFile object.

That way, TasksFile can efficiently store whether the filename is unique and cache the results.

This is also a necessary step on the way to efficiently providing access to file properties/YAML/frontmatter to searches.

How to Test

No response

[claremacrae]

Another way to address this would be to call getMarkdownFiles() at the start of the search and pass it in to each QueryRenderChild.isFilenameUnique() call.

So there would be only one expensive call per render of a query - rather than one per task rendered.

[claremacrae]

Another way to address this would be to call getMarkdownFiles() at the start of the search and pass it in to each QueryRenderChild.isFilenameUnique() call.

So there would be only one expensive call per render of a query - rather than one per task rendered.

Doing this, the result is not as clear-cut as I would have hoped:

Number of Tasks	Original render time (ms)	New render time (ms)
1	6.299999952316284	13.700000047683716
25	42.799999952316284	36.699999928474426
50	80.60000002384186	79.30000007152557
100	146.29999995231628	157.10000002384186
150	199.30000007152557	188.60000002384186
200	270.89999997615814	243.10000002384186
250	388.89999997615814	307.39999997615814
500	648	549.5
750	1172.2999999523163	1035.6999999284744
1000	1436.1000000238419	1197.3999999761581
2000	3021.399999976158	3805.1999999284744
3000	4647.799999952316	9491.399999976158
4000	8601.600000023842	12144.300000071526
5000	9529.099999904633	8763.399999976158