Chapter 5: Realizing a Metadata Framework 191 5.8.2 Speed In addition to memory consumption, another performance issue is execution speed. Again, the fl exibility of the system, and the way it enforces that all metadata properties and objects adhere to some ontol- ogy, causes performance penalties in execution speed compared to a simpler application-dependent metadata management system. There is no way around it; our framework is inherently slower than any opti- mized metadata management system for a single application. We can increase the query speed and the overall performance by using in- memory caches and indexing the data in all possible ways, but those consume more memory. The main problem is choosing how much memory we can use in order to gain speed or how slow the system can be while still remaining usable. Practical tests with our non-optimized framework show that reading or querying metadata from Metadata Engine is not an issue. However, writing data into the system tends to be a problem. Metadata Engine is designed to be used in environments where new metadata objects are mostly user-created or come via e-mail, MMS, or by using other messaging systems. There are no signifi cant issues as long as creating a new metadata object and adding its properties only takes a few milliseconds. The real challenges are related to importing tens of thousands of media items in one go. This may occur, for example, when using our framework for the fi rst time and the user wants to transfer all metadata from an old media server to our frame- work. It will take time. What we can learn from the above is that the system must remain responsive, even while importing large amounts of metadata. There- fore, our APIs are required to be asynchronous whenever there is a delay above 500 ms (such as while importing tens of thousands of images). Asynchronous API calls carry out the operation in the back- ground, allowing the user to perform other tasks simultaneously. Importing metadata usually needs to be done only once. However, our framework also regards all user actions as metadata and stores them too. All human-initiated events, including opening a media item, watching it, and editing it, occur somewhat infrequently from the computer’s point of view. No one can create usage events rapidly enough to impose any effect on the system. Applications, however, can do it more easily. When designing an application that constantly adds new metadata objects, modifi es them, and thus creates a torrent of events, then our framework is not best suited to that task. The speed of the system is one of the major issues of any system component. They must be optimized for both their memory consump-