I would like to thank people for the response to the thread on performance tuning the Fedora Desktop. The responses have been very helpful. Below is what I have written up as a result of the comments I got. APPLICATIONS There are a large number of packages that could be considered part of the desktop. However, the most critical ones appear to be the mail clients, web browsers, word processors, and window manager. There were several comments about up2date/rpm related software also. A short list of important apps rpms: evolution mozilla ooffice gnome-terminal gnome-* *FIXME* would like to narrow this down to a list of executables *FIXME* PERFORMANCE PROBLEMS The performance issues with Desktop applications differs signficantly from the tradition single-threaded, batch-oriented benchmarks, like SPEC CPU2000. The desktop applications often have multiple threads. The footprints of the desktop applications are larger due to the number of shared libraries being used to do GUI and network related operations. Also users typically have several desktop applications open concurrently. As a result, Cache and paging are more likely to be issue with desktop applications. Optimizing for code size may be boost performance more than trying to use aggressive compiler optimizations that increase program size. Latency is more of an issue than throughput for the desktop applications. How long it takes for the action for a mouse click to be observed is more important than the machine can do a certain number of the actions in a given period of time. Interactivity is the issue; ideally, the actions should be below a person's threshold of detecting, for example a new window appears to pop up instantly but in reality it may take 10millisecond to do. Some latency issues may be outside the applications control. For example performance limited by DNS lookups to convert URL address into IP number. Actual rate that network provides data to web browser affect the perceived performance. With the exception of eliminating the dependency on the outside application, nothing on the local machine is going to improve performance. METRICS Unfortunately, many people's metrics for desktop applications were literally eyeballed, click a menu item see how long it takes for the result to occur. This is difficult to automate and script. We really want benchmarks where at the very least the actual measure does not require the person to measure by hand and then transcribe the resulting measurement to a machine readable format. Better still would an automated test like the performance tracking for GCC, http://people.redhat.com/dnovillo/spec2000/. This would make it easier to see when a code change fixed a performance problem (or introduced a performance problem). Wall clock time obtained from strategic printf of gettimeofday and strace were uses to get timing informatoin. Memory footprint of desktop application another metric of interest. The larger the memory footprint the more time it takes to start up. Also large memory footprint application are likely to have more cache misses and page fault, slowing the execution of the program. File accesses can also affect performance. When a desktop application is initially started shared library files need to be opened. Additionally, other file with preference information may be opened. In the case of Nautilus it may need to examine all the files in the directory it is browsing. Restructing the code to reduce the number of file access could improve the performance of applications. Round trip for X protocol affect the latency of operations. For example client sends X server message to do operation and acknowledge when the operation is complete can hurt performance over channels with long latency. This type of problem affected the graphical installer for a distribution of linux for s390. Every screen update required a round trip, which tripled the install time because a round trip latency was encountered for every update of the progress bar. PERFORMANCE TUNING TOOLS The data collectedy by the performance tools does not need to be exact, in many cases tools are being used to identify areas of code that will make a difference in performance. Whether 30% or 33% percent of the time is spent in a single rountine is not that big a difference. Currently, developers are looking for the things that have large impact on performance. Tools that significantly slow the execution of the code change the interactions between the user and the code. The instrumention can also change the interactions between instrumented and uninstrumented code. The slowness of the code and the perturbations of the system make detailed instrumentation less attractive to developers. Some of the optimization work is finding inappropriate algorithms or data structures used for particular tasks. Knowing the context that a function is called is important, so call graph information is essential. Call graphs for desktop applications are complicated due to recursive code, signal handling, and co-routines. Some GUI developer have developed profiling tools. For example sysprof by Soeren Sandmann for Gnome (http://www.daimi.au.dk/~sandmann/sysprof-0.02.tar.gz) and Mozilla performance tools http://www.mozilla.org/performance/. COURSE OF ACTION 1) Develop Desktop benchmarks Need to have some benchmarks to determine performance. Very incomplete list of suggested benchmarks: -gdm login to setup desktop -menu select desktop program _____ to time desktop program ready to use -cat text file to xterm Should have clear procedures for each so the results can be generated by anyone and compared. It would be a bonus if can run benchmark from commandline, so the data collection can be automated. 2) Get baseline metrics on benchmarks Have baseline to determine whether code changes are increasing or decreasing performance. Allow us to avoid the nebulous "feels faster" and "feels slower". Also use this data to find out where the most significant problems are, for example important application take ten minutes to start. 3) Improve performance monitoring/tuning tools and scripts *FIXME* make the tuning tools information more concrete *FIXME* a) Need trigger mechanism to start and stop profiling data collection on certain conditions or events. For example start profiling when menu item selected and stop profiling when action complete. This would avoid interesting samples getting lost in the sea boring long term sampling. b) Better tools to map out memory foot print. Reducing memory use is likely to help performance by reducing time to load application and related shared libraries. Related to this is consider tools to reorder functions in code to get better locality (like grope) and produce hot and cold code. c) Easier means of navigating performance data. For example break down of time spent in parent and children. Maybe pull some of the sysprof data analysis into oprofile data analysis. Also maybe use the OProfile plug-in for eclipse to visualize data. d) Take advantage of the uses of shared libraries in code to insert instrumentation between the application and the function in the shared library when the library is load/linked in. -Will