Abstract:
The performance of a boot sequence is improved by presenting the user with easy to read information concerning the performance cost of each boot time application, and allowing the user to remove processes from the boot sequence or uninstall them altogether. Processes associated with the boot sequence are identified, and their corresponding performance cost is determined as percentage of the performance cost of the entire boot sequence, or according to the time they take to execute. The identified processes and their associated performance costs are presented to the user, along with a user interface component for selecting processes to remove from the boot sequence and/or uninstall. Responsive to input from the user, selected processes are removed from the boot sequence and/or uninstalled as directed.

Description:
TECHNICAL FIELD 
     This invention pertains generally to improving computer performance, and more specifically to enabling end users to intelligently and easily improve their boot sequence performance. 
     BACKGROUND 
     Poor performance of personal computers is a common user complaint. One of the most common performance issues is the length of time it takes for a computer to start-up. As more and larger applications are loaded at boot time, this problem becomes progressively worse. Unfortunately, the typical computer user is unable to improve computer boot sequence performance because s/he 1) does not know the approximate cost of the various processes in the boot sequence; 2) does not know that multiple processes started at boot time might be associated with the same application; and 3) does not know how to remove undesired applications and processes from the boot sequence. 
     Commercial tools are available to show the applications started during the boot process, and to allow the user to remove them. However, these tools do not indicate what gain that would result from removing which application, or the multiple processes that can be associated with individual different applications. Other tools, such as Microsoft&#39;s Bootvis®, provide monitoring of system resources during the boot process. Bootvis® is a performance tracing and visualization tool to help system designers and software developers identify performance issues for boot/resume timing while developing new products or supporting software. However, Bootvis® is not a tool that can improve boot performance for end users. 
     It would be desirable to enable end users to intelligently and easily improve their boot sequence performance. 
     SUMMARY 
     The performance of a boot sequence is improved by presenting the user with easy to read information concerning the performance cost of each boot time application, and allowing the user to remove processes from the boot sequence or uninstall them altogether. Processes associated with the boot sequence are identified, and their corresponding performance cost is determined as percentage of the performance cost of the entire boot sequence, or according to the time they take to execute. The identified processes and their associated performance costs are presented to the user, along with a user interface component for selecting processes to remove from the boot sequence and/or uninstall. Responsive to input from the user, selected processes are removed from the boot sequence and/or uninstalled as directed. 
     The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram illustrating a system for improving boot sequence performance, according to some embodiments of the present invention. 
     
    
    
     The Figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein. 
     DETAILED DESCRIPTION 
       FIG. 1  illustrates a system  100  in which a Boot Sequence Manager  102  enables users to intelligently and easily improve their boot sequence performance, according to some embodiments of the present invention. It is to be understood that although various components are illustrated in  FIG. 1  as separate entities, each illustrated component represents a collection of functionalities which can be implemented as software, hardware, firmware or any combination of these. Where a component is implemented as software, it can be implemented as a standalone program, but can also be implemented in other ways, for example as part of a larger program, as a plurality of separate programs, as a kernel loadable module, as one or more device drivers or as one or more statically or dynamically linked libraries. 
     As illustrated in  FIG. 1 , a Cost Analysis Component  101  of the Boot Sequence Manager  102  is loaded early in the system boot sequence, in order to monitor all boot related processes  103 . For each boot time process  103 , the Cost Analysis Component  101  monitors process  103  activity (e.g., central processing unit (“CPU”), memory, disk, network, etc., usage) and estimates the performance of the process  103  relative to the overall boot sequence. Each process  103  is monitored during the boot sequence to determine its performance cost. The Cost Analysis Component  101  estimates each process&#39;s  103  cost to boot sequence performance, represented as, e.g., a percentage or a time cost. The implementation mechanics of monitoring boot related processes  103  and determining their performance is within the skill set of those of ordinary skill in the relevant art, and the usage thereof within the context of the present invention will be readily apparent to one of such a skill level in light of this specification. 
     Additionally, in some embodiments of the present invention, a Process Initiation Monitor Component  105  of the Boot Sequence Manager  102  monitors each process  103  to determine whether it was initiated directly as part of the boot sequence or indirectly, by another process  103  or application  107  in the boot sequence. For example, if a single application  107  initiates three processes  103 , then usage metrics of all three should be included in the calculated cost of the single application  107 . By associating each process  103  with the application  107  that spawned it, the Process Initiation Monitor Component  105  can assign a discrete performance cost to each application  107  in the boot sequence. The implementation mechanics of determining which application  107  spawned which process  103  is within the skill set of those of ordinary skill in the relevant art, and the usage thereof within the context of the present invention will be readily apparent to one of such a skill level in light of this specification. 
     Once the performance costs have been calculated, a Boot Sequence Management User Interface  109  displays a list  111  of applications  107  and/or processes  103  started by the boot sequence. The estimated performance cost of each application  107  and process  103  in the boot sequence is also displayed. In other words, the Boot Sequence Management User Interface  109  shows the applications  107  and processes  103  that are automatically started at boot time, with the corresponding performance cost estimate for each. The Boot Sequence Management User Interface  109  provides an easy mechanism (e.g., a button or other user interface component, not illustrated) for the user to select to either remove an application  107  or process  103  from the boot sequence, and/or to uninstall it altogether. Responsive to input from the user, the selected applications  107  and/or processes  103  are removed from the boot sequence and/or uninstalled as directed. The implementation mechanics of presenting such information to a user, receiving corresponding user input and removing and uninstalling applications is within the skill set of those of ordinary skill in the relevant art, and the usage thereof within the context of the present invention will be readily apparent to one of such a skill level in light of this specification. 
     In one embodiment of the present invention, the Cost Analysis Component  101  weighs computing resources in heavy contention (e.g. maxed out CPU or physical memory swapped to disk) more heavily than resources that are in more abundant supply (e.g., physical disk access, network access on fast connection). This involves calculating relative process  103  resource usage at a component level. For example, suppose that a given process  103  uses X CPU cycles during the boot sequence. Suppose further that the total number of CPU cycles used by all processes  103  during the boot sequence is Y. The given process&#39;s  103  CPU cost would be calculated as a percentage X/Y. This cost could also be expressed as, e.g., a number of seconds X/Y*(boot time). 
     In this embodiment, the Cost Analysis Component  101  also determines relative resource contention, so as to implement weighing. Suppose that during the boot process CPU usage is at an average of 60% of capacity and, for example, disk input/output (“i/o”) is running at an average of 30% of capacity. In this scenario, the Cost Analysis Component  101  could assume that CPU usage should be weighted two-to-one over disk i/o, which can be expressed as ((pct cpu cost)*2+(pct disk i/o cost)*1)/3. Of course, the actual weightings used for the various computing resources could vary as desired, based on, for example, the type of resource, results of lab testing, user or administrator preferences. etc. The implementation mechanics of determining which resources are being most heavily utilized during the boot sequence and of assigning weights accordingly is within the skill set of those of ordinary skill in the relevant art, and the usage thereof within the context of the present invention will be readily apparent to one of such a skill level in light of this specification. 
     As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the portions, modules, agents, managers, components, monitors, interfaces, functions, procedures, actions, layers, features, attributes, methodologies and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions and/or formats. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the portions, modules, agents, managers, components, monitors, interfaces, functions, procedures, actions, layers, features, attributes, methodologies and other aspects of the invention can be implemented as software, hardware, firmware or any combination of the three. Of course, wherever a component of the present invention is implemented as software, the component can be implemented as a script, as a standalone program, as part of a larger program, as a plurality of separate scripts and/or programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of skill in the art of computer programming. Additionally, the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Furthermore, it will be readily apparent to those of ordinary skill in the relevant art that where the present invention is implemented in whole or in part in software, the software components thereof can be stored on computer readable media as computer program products. Any form of computer readable medium can be used in this context, such as magnetic or optical storage media. Additionally, software portions and means of the present invention can be instantiated (for example as object code or executable images) within the memory of any programmable computing device. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.