Investigation: what's causing the speed bottle-neck?

[nienna73]

Is it the front-end? It could be paradigm organization, it could be inefficient result parsing. We need to look into this.

[nienna73]

Some places to consider looking:

I would start with the initial search results page.

• How long does it take to fetch the results from the backend?
• What happens to the results immediately after they're fetched?
• How many files are used in the initial search results page?
• How many processes are happening?
• Could any of these processes happen in parallel? As in, could the page be rendered without the info icon, book icon, speech, something like this and have those elements appear as they're ready?
• Are variables being passed through many many files?
• Are there expensive for loops?
• Are there lots of if statements in a row?
• Are there expensive try-catch blocks? (all try-catch blocks are expensive)
• How often are we accessing memory?
• Can some things be cached? (not sure if this is even possible on the frontend, I don't think it is)
• Are we unnecessarily moving large amounts of data between variables, files, etc.? (I think this is the third variation of this question, I just want to be sure)
• Does anything else stand out as weird? Unnecessary? Excessive? Inconsistent?

After that, we can take a look at the paradigms page, but we want search results showing up quickly first.

[M1Al3x]

The speed issue comes mostly from the backend. The main difference from the production version is that some of the processes are expected to be finished for a page to be loaded. It is exactly the same for both: paradigm page and search page. Speed performance has been improved drastically and I'd be willing to hear if you expect even stronger improvement.

[M1Al3x]

The entire process was taking 8 seconds in the beginning, and now it has been reduced to 1 second.

[aarppe]

We usually close such issues as a collective decision, when we ensure that the solutions have been collectively verified.

[M1Al3x]

Sure. My mistake.