When the Application Server lists all features in a view the view's filter is executed and the results are returned. This is usually performed in a few milliseconds. However to know the views a given feature is member of the Application Server has to evaluate the filter in all defined views, which might of course take considerably longer depending on your amount of views, the complexness of the filter criteria in these views and the depth of your view tree.

Since querying all views a given feature is member of is done frequently when you base your feature permissions on views, the Application Server uses an in-memory cache.

The basic principle behind view member caching is that behind the scenes the view members are evaluated on specific events and when the Application Server then queries for members of a specific view  then it does not have to execute the filter but uses the members it cached last time the filter was evaluated. This view members cache is only used for evaluating feature permissions. When you list the elements of a single view the Application Server will always execute the view filter of that view.

Of course this implies that (in rare cases) you might experience the situation that privileges for features that are defined on a view are not immediately propagated to the view members. Therefore the actual privileges a user has on a feature at a specific point in time are only as up to date as the cache. If you have features where this could be a security concern assign privileges directly to those features.

As with other caches the view member cache resides in memory but it is persisted if you shut down the application server.

The view members cache is automatically updated whenever a feature observations or a view is modified. Modifications to features an views cause an immediate update of the view member cache if the Application Server is not already running a view member cache update, else the update will be performed as soon as the currently running update has finished. For performance reasons modifications to observations will cause a delayed update, i.e. the system only remembers that an update is necessary but will perform the update when an internal caching timer elapses next. This timer elapses every 30 seconds.