As your Web Property grows and the number of assets gets larger, the ability to search for assets with specific characteristics becomes even more compelling. However, we must be careful with how we implement the Searches property because searching may require a great deal of system resources. Performance can certainly become a concern if searches are too wide or are used too often.
The following Searches methods must iterate the entire CMS Content Repository to retrieve the objects requested and should be used sparingly:
These searches should only be used when the business needs demand that the entire Repository be searched. If the search can be localized, it should be done.
It is wise to use GetByGuid rather than GetByPath or GetByUrl when you are looking for a specific object. Searching for assets that could be moved or could have duplicates can pose an additional hurdle to using the Searches methods effectively. It can also help to organize the hierarchies in the Web Property such that the number of child containers doesn't exceed 15, the number of items in a container doesn't exceed 300, and the number of levels of depth doesn't exceed ten. CMS will allow you to exceed these thresholds, but the consequences could be a less responsive site, especially when searching for assets.
One exception to the limited use of Searches has to do with accessing a specific item within a known collection. When the Item property of a collection is requested, CMS must hydrate the entire collection to return just the single instance. However, using a Searches method results in the hydration of just the individual instance. So, in this case performance will actually be improved by using a Searches method.
If the resulting search doesn't result in the collection of assets that are needed, it may be helpful to combine the results of more than one search using the Union method, creating a unified custom collection of assets to manipulate.