The list of views of each DB is backed by the ViewsForDatabase data structure, which does not have copy-on-write semantics.

When creating or dropping a view, this data structure is copied is several places, so performance degrades with the number of views:

• Creating/dropping a view has O(N) complexity where N=number of existing views.
• Creating/dropping N views has O(N^2) complexity

This could be solved by implementing copy-on-write semantics or some similar kind of incremental update strategy for ViewsForDtabase.

Practical impact

In practice performance degrades noticeably when a DB has 1000s of views or viewful timeseries collections.

With N=15000 views, on a 3 node RS, optimized build, m7g.2xlarge VM w/ gp3 storage):

• Creating 2000 views --> 35 seconds (18ms per view)
• Drop 2000 views --> 75 seconds (38ms per view)

Frame graphs for create view

In those flame graphs most of the time spent in the commit of the WUOW (e.g. CollectionCatalog::write) and CollectionCatalog::createView copying and destroying the ViewsForDatabase data structure.

Replica set primary:

Replica set secondary:

Frame graphs for drop view

 Those frame graphs show the known performance issue in SERVER-78615 aside from the same performance impact of copying/destroying ViewsForDatabase:

Replica set primary:

Replica set secondary: