Hi Daniel,

The issue passed to the R&D team in the original case was instructing to address the issue of search triggering each time a key was pressed in the search box.  This was resolved by waiting for a delay in user input before starting the search.  Since this was the reported issue, the QA testing as carried out and successfully passed by inputting a series of characters into the search box and checking that the search command only issued when a pause was detected in the typing.  This has a side effect of slightly improving the performance, but the main aim was to reduce the unresponsive time which resulted from multiple concurrent versions of the search (i.e. one from each key press) being triggered and processed simultaneously.

We now have received a new task in the R&D team to look into the performance of the search function in your case, which we will be working on soon.

Thanks,
   Carl

The same feature is available on every other screen (where the search result is presented almost instantaneously). On our original case we  reported a lag on the resource screen (meaning the system would froze for 40+ seconds) - we provided a screen recorded as an evidence for this issue.

 I was assuming that when the solution was developed they would address the lagging issue reported and not just adding an extra delay in the user input before executing an inefficient search. 

Looking forward to seeing this issue resolved in the next PSO version.