While care has been taken to maintain high performance, use of the secured repository does have some impact on the performance of the repository and, in some cases, the impact is considerable.
For access control defined at the item descriptor level (e.g. Repository.getItem(), MutableRepository.createItem(), MutableRepository.addItem(), MutableRepository.updateItem()) the overhead of handling access checks amounts to the testing of the access control list for the item descriptor. This is normally minimal.
The exception to this rule is with the use of the RepositoryView.executeQuery() and RepositoryView.executeCountQuery() family of methods whenever ACLs are specified for individual repository items. In this case, the ACL of each repository item must be consulted to determine if it should be allowed in the result of the query, or counted as part of a count query. If the result set is large, the time required to parse and check all of the ACLs may be large. Furthermore, in the count query case, a full query must be done and its results counted. Thus, if your application is using count queries to limit expensive queries, the features afforded by a secured repository will be very expensive.
Access control overhead at the repository item level is noticeable, but is incremental. When the repository item is loaded its ACL will be parsed prior to any access checking. Results of ACL parsing are cached to improve performance where possible. If ACLs are not being stored for each individual repository item, no parsing needs to be done beyond what is done during the initialization of the secured repository.
Because the secured repository sits on top of an underlying repository, you can consider whether features that need best possible performance should be written to use the underlying repository rather than going through the secured repository at the cost of the security features.
