Tree performance for large collections

[tomcrane]

Compare the tree rendering times for the UV and the previous Wellcome Player:

• UV: http://wellcomelibrary.org/item/b19974760
• Player: http://wellcomelibrary.org/plyr/b19974760

The UV is getting stuck somewhere here.

Also the tree should default to the date structure, if the collection nodes have navDate properties.

[LlGC-szw]

We have an example of this for a Newspaper with navDate properties:

http://universalviewer.io/examples/?manifest=http://dams.llgc.org.uk/iiif/newspapers/4651124.json#?c=0&m=0&s=0&cv=0&z=-0.3508%2C-0.0758%2C1.7016%2C1.5166

[nicolasfranck]

We have a collection of 15000 manifests. As expected, it crashes in the browser when clicking the tab "index".

http://shared.ugent.be/local/vooruit.html#?c=0&m=0&s=0&cv=0&z=0.0589%2C0.2372%2C0.9453%2C0.5168

On the other hand, the above mentioned tree from tomcrane does not. Is this because of the tree structure: it uses a collection of collections, mine is a flat collection of manifests. Are there any restrictions we need to take into account?

[edsilv]

Hi, I've been working on moving the tree to a separate component (as discussed by the implementers group).

http://edsilv.github.io/iiif-tree-component/test/

Here you can see it's loading Chemist and Druggist. The time it takes to appear is due to the size of the manifest being downloaded (normally you'd see the UV spinner for that). Once it appears, try toggling between 'date' and 'default' sorting. It should take about a second to initialise.

In separating it out I've had an opportunity to optimise the code. I think the performance problems should be fixed once I re-integrate this component. Lots more work needed on that though.

I tried your manifest @LlGC-szw and there appears to be an invalid date for "Abergele & Pensarn visitor (1915-04-03 Supplement)"

navDate: "1915-04-03 SupplementT00:00:00Z"

Perhaps a regex gone wrong somewhere?

[edsilv]

Closing as solved by #319