Abstract: A computing system includes a first memory that stores IO data, a second memory, and a boot manger. A pre-fetch manager pre-fetches IO data from the first memory to the second memory when the boot process is initiated. A detector component determines that an amount of the IO data pre-fetched by the pre-fetch manager has fallen behind a rate at which the pre-fetched IO data is executed by the computing system. An optimizer component causes the boot process to be paused to create a pause window and causes the pre-fetch manager to pre-fetch during the pause window a subset of the IO data. The subset has a magnitude that is determined to result in the amount of IO data pre-fetched by the pre-fetch manger substantially matching the rate at which the pre-fetched IO data is executed when the pause window is ended and the boot process is resumed.

Abstract: Systems and methods for monitoring operational performance of at least one application containing no explicit instrumentation are described. Data relating to the operational performance of the application can be obtained and provided to a telemetry server for analysis without the use of diagnostic instrumentation within the application. Generic and targeted performance data can be obtained using responsiveness components within a computing operating system.

Abstract: Two different process management views can be displayed, and a user can request to switch between the two views. The user can select a process in either view and have the selected process terminated. One view is a simplified view that identifies processes and whether they are non-responsive. The other view is an expanded view that identifies processes and the amount of various system resources used by each of those processes. Various additional information can be displayed in the expanded view, such as identifiers of various windows, tabs, and/or services associated with each of the processes.

Abstract: Execution traces are collected from multiple execution instances that exhibit performance issues such as slow execution. Call stacks are extracted from the execution traces, and the call stacks are mined to identify frequently occurring function call patterns. The call patterns are then clustered, and used to identify groups of execution instances whose performance issues may be caused by common problematic program execution patterns.

Abstract: A description language and a tool for identifying, analyzing and addressing performance issues in event traces. With this language, a behavior descriptor may be defined to describe a simple behavior within a performance trace, by specifying values for a relatively small number of attributes. Even a relatively unsophisticated user can define behavior descriptors, but complex behaviors may be defined based on interactions between multiple behavior descriptors. A trace analysis tool may use a library of behavior descriptors to identify performance issues in performance traces by matching behavior descriptors to the performance trace. This analysis may be used in any number of ways, including reporting to a user detected performance issues reflected in a set of performance traces, filtering a set of performance traces to remove those performance traces corresponding to known performance issues or prioritizing efforts to resolve performance issues.

Abstract: Two different process management views can be displayed, and a user can request to switch between the two views. The user can select a process in either view and have the selected process terminated. One view is a simplified view that identifies processes and whether they are non-responsive. The other view is an expanded view that identifies processes and the amount of various system resources used by each of those processes. Various additional information can be displayed in the expanded view, such as identifiers of various windows, tabs, and/or services associated with each of the processes.

Abstract: Execution traces are collected from multiple execution instances that exhibit performance issues such as slow execution. Call stacks are extracted from the execution traces, and the call stacks are mined to identify frequently occurring function call patterns. The call patterns are then clustered, and used to identify groups of execution instances whose performance issues may be caused by common problematic program execution patterns.

Abstract: Systems and methods for monitoring operational performance of at least one application containing no explicit instrumentation are described. Data relating to the operational performance of the application can be obtained and provided to a telemetry server for analysis without the use of diagnostic instrumentation within the application. Generic and targeted performance data can be obtained using responsiveness components within a computing operating system.

Abstract: A description language and a tool for identifying, analyzing and addressing performance issues in event traces. With this language, a behavior descriptor may be defined to describe a simple behavior within a performance trace, by specifying values for a relatively small number of attributes. Even a relatively unsophisticated user can define behavior descriptors, but complex behaviors may be defined based on interactions between multiple behavior descriptors. A trace analysis tool may use a library of behavior descriptors to identify performance issues in performance traces by matching behavior descriptors to the performance trace. This analysis may be used in any number of ways, including reporting to a user detected performance issues reflected in a set of performance traces, filtering a set of performance traces to remove those performance traces corresponding to known performance issues or prioritizing efforts to resolve performance issues.

Abstract: Described is an adaptive scheduler associated with a desktop window manager that dynamically controls the rate at which graphics frames are composed. Values corresponding to performance when composing a frame are measured, and the frame composition rate is adjusted as necessary based on the values. The measured data is sampled to provide smooth adjustments. The sampled data is evaluated as to whether the current frame rate is too slow, too fast, or acceptable. If too slow, the frame rate may increased relative to the refresh rate, while if too fast, the frame rate is decreased relative to the refresh rate. In one implementation, the frame rate is too fast if a count of missed frames achieves a missed threshold value, or if a count of late frames achieves a late threshold value. The frame rate is too slow if a count of early frames exceeds an early threshold value.

Abstract: Described is an adaptive scheduler associated with a desktop window manager that dynamically controls the rate at which graphics frames are composed. Values corresponding to performance when composing a frame are measured, and the frame composition rate is adjusted as necessary based on the values. The measured data is sampled to provide smooth adjustments. The sampled data is evaluated as to whether the current frame rate is too slow, too fast, or acceptable. If too slow, the frame rate may increased relative to the refresh rate, while if too fast, the frame rate is decreased relative to the refresh rate. In one implementation, the frame rate is too fast if a count of missed frames achieves a missed threshold value, or if a count of late frames achieves a late threshold value. The frame rate is too slow if a count of early frames exceeds an early threshold value.