search

gbv / cocoda

A web-based tool for creating mappings between knowledge organization systems.
https://coli-conc.gbv.de/cocoda/
MIT License
39 stars 5 forks source link

RVK instance is slow #513

Closed nichtich closed 4 years ago

nichtich commented 4 years ago

The instance at https://coli-conc.gbv.de/cocoda/rvk/ is slower than dev, this may be caused by concept lists. We could limit maximum number of concept list entries if this helps.

stefandesu commented 4 years ago

I can imagine that this has to do with the concept lists, especially because the one list we have in there has 250 entries, which means 250 additional instances ConceptListItem. We could limit the number of entries, but that would impede the concept list feature. Maybe it would be better to add #4 after all...

Alternatively, I could try to figure out how to make concept lists more efficient. Maybe by creating the whole list in-line instead of using components. If you think about it, we have 250 instances of ConceptListItem which in this case add 500 instances of ItemName (250 for the concepts and 250 for the scheme in front of the concepts which seems very unnecessary), as well as 250 instances of LoadingIndicator which are shown when narrower concepts are loaded (also seems very unnecessary considering that there are no narrower concepts in a flat list). Each ItemName in turn has a router-link as well as notation-text (which is defined in ItemName). If you add this up, we have a total of a whopping 2000 Vue components if I'm not mistaken, that is simply way way too much for a single list...

nichtich commented 4 years ago

In lists we don't need full functionality of ConceptListItem. At least the Concept Scheme notation could be fixed. It would also be ok to not update labels when the language is changed. What's needed is dynamic indicator which concepts have been mapped. With #508 we could get dynamic lists via API that are likely smaller, e.g. 40 recently mapped concepts etc. To manually update a list's view we could add a reload button at the bottom.

stefandesu commented 4 years ago

In lists we don't need full functionality of ConceptListItem. At least the Concept Scheme notation could be fixed. It would also be ok to not update labels when the language is changed.

What I now did was to replace ItemName with getting the notation and prefLabel directly. Also, LoadingIndicator is now added with a v-if so it's only there when it's actually needed. I didn't think it was reasonable to have two different versions of ConceptListItem depending on whether it's a list or a tree view. Also, not updating labels when the language is changed is way more complicated than updating them because I don't have to do anything to have them updated. Not having them updated would mean reimplementing a whole bunch of things. I also don't think it would help much with performance.

We could take this one step further and include everything that's in ConceptListItem into ConceptList because that's the only place where the component is used.

What's needed is dynamic indicator which concepts have been mapped.

This is fortunately outside of ItemName and was therefore not affected by my changes.

To manually update a list's view we could add a reload button at the bottom.

I'll add this for lists then are loaded from a URL.

stefandesu commented 4 years ago

Oh btw, I can't really say if all this actually helped with performance because I personally don't see any performance problems that seem related to long lists.

stefandesu commented 4 years ago

Closing in favor of #208.