根據mentor的推薦，儘量少用uvm_config_db,因爲uvm_config_db是一個數據庫，使用正則表達式匹配所有結果，如果數據庫過大會影響驗證平臺性能。但是同時也提到性能與方法學乃至OOP有一個trade off.
這裏幾個減少uvm_config_db的方法：
(1) 數據結構粒度不要太小，如下代碼：
uvm_config_db #(int)::set::(this, "*", "id", id);
uvm_config_db #(string)::set::(this, "*", "name", name);如果id和name可以歸爲一類，那麼最好：
class config;
int id;
string name;
endclass : config
uvm_config_db #(config)::set::(this, "*", "cfg", cfg);
(2) 使用直接傳遞
使用直接賦值語句代替set, get.這種方法很具有爭議，因爲直接賦值影響了重用性，違反了OOP中只能對數據成員進行method操作的原則。因此建議適當使用，例如比較好的方法是在agent內部使用直接賦值，其上結構使用config_db.原因是agent是最小功能單元，內部結構基本不會改變，複用粒度一般都在這一層。上一層可能會有env,也可能沒有，env對agent的傳遞最好使用config_db.
(3) interface傳遞的考慮
這一部分可以算是上面兩種方法的結合的考慮，目的是減少config_db中interface的傳遞數目。相對於第一種方法，將所有interface包含在一個對象中，只使用config_db傳遞該對象，各個package component只取自己需要的interface handle.而對應第二種方法，可以將interface獨立做成一個package,所有interface包含在這個包中，需要使用時import這個package,然後使用賦值語句把interface handle傳遞給configuration.
其他改善uvm_config_db性能的方法有：
(1) 搜索路徑少用正則通配，儘量精確，特別是直接使用*是一種不好的習慣，會給今後平臺增加組件或者與其他模塊配合時帶來問題。
(2) 不要用config_db來傳遞大量變化的內容，這樣的通信會沒有效率，可以採用TLM通信或者引用handle
以上各條需要根據實際情況進行調整，針對性能和重用性進行適當的調整，偏向兩個極端都是不好的選擇。
