Hi @luffySF
Please be as much secific as possible.
Your request fir help is very vague.
What do you mean by "a bit slow".
How slow it is?
Is it always that slow?
How fast you expect it to be?
What vesion of utPLSQL are you using exactly?
What DB version are you using?
How many objects are there in HR shema?
How many users are using your DB?
....

There ahe hundreds of factor that can cause slowness.
The more background you provide, the better chances for getting valuable help.

Hor now I can't help you, given the info you provided.

Hi @jgebal

Thank you for your reply!
The API of ut3.ut.run takes about 7 seconds to execute in my environment. I expect it to be less than 2 seconds.
The vesion of utPLSQL i'm using is v3.0.4 . and the DB is oracle 11g.
There are about hundreds of objects in HR schema ,and eighty user are using the DB.

As the same time , I found that the execution time of
ut.run('hr.test_apply_bonus.test_case_one') and ut.run('hr.test_apply_bonus')
is almost same.

However , the execution time of ut.run(ut_varchar2_list('hr.test_apply_bonus.test_case_one','hr.test_apply_bonus.test_case_two')) is about two times of ut.run('hr.test_apply_bonus.test_case_one').

that's all !

I'm looking forward to your reply soon. thank you very much !

Can you update to 3.1.2?
There were several changes in framework since 3.0.4
I would like to know if you see similar issues with latest version

Here you can find releases and release notes.
https://github.com/utPLSQL/utPLSQL/releases

One more thing that comes to my mind.
Does the user executing ut.run have access to DBA views? Can you query dba_objects/dba_source?

If nit, that can be a bottleneck, as the ALL views are significantly slower.
Another question.
Is the slowness showing always or only sometimes?
Do your active users compile packages frequently?

The slowness always happens. compile not frequently.

the Profiler is provided below.

Please try 3.1.2 and let me know how tgat works for you.
There is a session level cache that should drastically improve performance on test rerun even with 3.0.4.

Thanks for providing profiler info.
This shows that cache was not used.
Do you always run tests in new session?

If your package spec is always recompiled before tests there is not much we can do.
utPLSQL needs to chceck if source of packahe specifications have changed and scan source cide to identify annotations.
The only way around it would be to implement #631

I've had a look at performance of Oracle 11g/12.1/12.2/18 when it comes to querying data-dictionary.
It seems that by default 11g (out of the box DB) is performing worst.

Can you try to gather stats on system and see if that affect utPLSQL by any degree?

begin
  dbms_stats.gather_system_stats;
  dbms_stats.gather_fixed_objects_stats;
end;
/

Another step would be to assure that use has one of the privs:
grant select any dictionary to ...
grant select_catalog_role to ....

Let me know if you see any improvement

@luffySF - are you able to install the framework from github?
If so, can you try the feature branch: https://github.com/utPLSQL/utPLSQL/tree/feature/suite_query_api

This branch has a very different approach to fetching suites. Could give you a huge boost.
Since you're the one that encountered performance issues, it would be great to get feedback from you.

Please let me know if that solution gives better/worse performance.

@luffySF
Can you upgrade to 3.1.3 and let us know if it is better?
There are many startup performance inprovements in 3.1.3
Thanks

No reply from @luffySF - closing