Profiling and Optimization - Revision history

Sardonyx Linden at 17:29, 25 June 2007

2007-06-25T17:29:25Z

← Older revision		Revision as of 10:29, 25 June 2007
Line 20:		Line 20:
	A list of profilers that we've used at Linden:		A list of profilers that we've used at Linden:
	* Shark (Mac) - my preferred profiler right now. Sampling profiler, but it still manages to have call chain information. Great UI. Unfortunately, can't use it for everything, as it's Mac only, and graphics stuff is very different on the Mac vs. PC.		* Shark (Mac) - my preferred profiler right now. Sampling profiler, but it still manages to have call chain information. Great UI. Unfortunately, can't use it for everything, as it's Mac only, and graphics stuff is very different on the Mac vs. PC.
	* oprofile (linux) - another sampling profiler. Has some third party UIs, call chain information via <code>--callgraph=<i>N</i></code>. ~~However, very~~ easy to use on Linux.		* oprofile (linux) - another sampling profiler. Has some third party UIs, call chain information via <code>--callgraph=<i>N</i></code>. Fairly easy to use on Linux.
	* VTune (Windows) - sampling and call graph profiler. The UI is terrible - but there aren't many other sampling profilers available on Windows.		* VTune (Windows) - sampling and call graph profiler. The UI is terrible - but there aren't many other sampling profilers available on Windows.
	* GlowCode (Windows) - instrumented call-graph profiler, but a lot faster than typical - so it runs in near real time. If you want call chain information on Windows, this may be the way to go.		* GlowCode (Windows) - instrumented call-graph profiler, but a lot faster than typical - so it runs in near real time. If you want call chain information on Windows, this may be the way to go.

Sardonyx Linden at 17:28, 25 June 2007

2007-06-25T17:28:59Z

← Older revision		Revision as of 10:28, 25 June 2007
Line 20:		Line 20:
	A list of profilers that we've used at Linden:		A list of profilers that we've used at Linden:
	* Shark (Mac) - my preferred profiler right now. Sampling profiler, but it still manages to have call chain information. Great UI. Unfortunately, can't use it for everything, as it's Mac only, and graphics stuff is very different on the Mac vs. PC.		* Shark (Mac) - my preferred profiler right now. Sampling profiler, but it still manages to have call chain information. Great UI. Unfortunately, can't use it for everything, as it's Mac only, and graphics stuff is very different on the Mac vs. PC.
	* oprofile (linux) - another sampling profiler. ~~No UI~~, no call chain information. However, very easy to use on Linux.		* oprofile (linux) - another sampling profiler. Has some third party UIs, call chain information via <code>--callgraph=<i>N</i></code>. However, very easy to use on Linux.
	* VTune (Windows) - sampling and call graph profiler. The UI is terrible - but there aren't many other sampling profilers available on Windows.		* VTune (Windows) - sampling and call graph profiler. The UI is terrible - but there aren't many other sampling profilers available on Windows.
	* GlowCode (Windows) - instrumented call-graph profiler, but a lot faster than typical - so it runs in near real time. If you want call chain information on Windows, this may be the way to go.		* GlowCode (Windows) - instrumented call-graph profiler, but a lot faster than typical - so it runs in near real time. If you want call chain information on Windows, this may be the way to go.

Rob Linden: +Template:Open Source Participate Box

2007-06-22T19:34:23Z

+Template:Open Source Participate Box

← Older revision		Revision as of 12:34, 22 June 2007
Line 1:		Line 1:
			{{Open Source Participate Box}}

	First, this article assumes that you're working with an existing and essentially complete piece of code or product that you want to optimize. However, if you are working on performance critical code (rendering code falls into this category, for example), you will have wanted to start thinking about performance long before you reach this stage. Premature '''micro'''-optimization is evil, but algorithmic optimization should always be in the back of your mind.		First, this article assumes that you're working with an existing and essentially complete piece of code or product that you want to optimize. However, if you are working on performance critical code (rendering code falls into this category, for example), you will have wanted to start thinking about performance long before you reach this stage. Premature '''micro'''-optimization is evil, but algorithmic optimization should always be in the back of your mind.

Doug Linden at 16:17, 21 June 2007

2007-06-21T16:17:27Z

← Older revision		Revision as of 09:17, 21 June 2007
Line 1:		Line 1:
	First, this article assumes that you're working with an existing and essentially complete piece of code or product that you want to optimize. However, if you are working on performance critical code (rendering code falls into this category, for example), you will have wanted to start thinking about performance long before you reach this stage. ~~A good article to read~~ is ~~this one: http://www.acm.org/ubiquity/views/v7i24_fallacy.html~~		First, this article assumes that you're working with an existing and essentially complete piece of code or product that you want to optimize. However, if you are working on performance critical code (rendering code falls into this category, for example), you will have wanted to start thinking about performance long before you reach this stage. Premature '''micro'''-optimization is evil, but algorithmic optimization should always be in the back of your mind.

	~~Secondly~~, ~~I would recommend reading~~ the ~~following article - if only to have an understanding~~ of ~~terminology that will be used. http://en.wikipedia~~.~~org/wiki/Performance_analysis~~

	Basic guidelines:		Basic guidelines:
	* ALWAYS profile before and while performing optimizations. There are ALWAYS surprises, and ~~the hot spot isn't always exactly~~ where you ~~think it is~~. Plus, a good profiler will help you figure out exactly what your problem is - whether it's memory access, CPU.		* ALWAYS profile before and while performing optimizations. There are ALWAYS surprises, and performance bottlenecks are often not where you expect them to be - especially if there are other people writing code besides you. Plus, a good profiler will help you figure out exactly what your problem is - whether it's memory access, CPU.
	* Iterate frequently. Don't do one profile, write a week's worth of code, then write another profile. As you change the code, the ~~hot spots~~ will change.		* Iterate frequently. Don't do one profile, write a week's worth of code, then write another profile. As you change the code, the bottlenecks will change. Don't spend a lot of time optimizing one piece of code down to zero when cutting it in half makes something else the bottleneck.

	= Profiling =		= Profiling =
Line 27:		Line 25:
	* Obviously, always optimize based on the results of a profile.		* Obviously, always optimize based on the results of a profile.
	* Always try to do algorithmic and architecture-based optimizations before code optimizations.		* Always try to do algorithmic and architecture-based optimizations before code optimizations.
	* Memory and cache considerations are often MUCH more important than instruction count. This is a relatively recent phenomenon. On some architectures, you can run dozens of instructions or more in the amount of time that it takes to fetch data from main memory. Thus, when optimizing, you may want to ~~actually pay~~ more ~~attention to~~ how your algorithms access data than the number of instructions that they use.		* Memory and cache considerations are often MUCH more important than instruction count. This is a relatively recent phenomenon. On some architectures, you can run dozens of instructions or more in the amount of time that it takes to fetch data from main memory. Thus, when optimizing, you may want to think more about how your algorithms access data than the number of instructions that they use.
	* Don't write assembly unless you absolutely have to. It's not easy to make cross-platform, and unless you are REALLY good, compilers are often better than you are. If you need to, restructure the C/C++ code to make it more clear to the compiler what you are attempting to do.		* Don't write assembly unless you absolutely have to. It's not easy to make cross-platform, and unless you are REALLY good, compilers are often better than you are. If you need to, restructure the C/C++ code to make it more clear to the compiler what you are attempting to do.
	* On the other hand, understand assembly if you're doing micro-optimizations. Profilers will tell you what line your problem is on according to the symbol database, but that line can expand out into hundreds of ~~lines of assembly~~, only one of which is the problem. If you ~~can figure out what assembly corresponds to what in~~ the ~~line of C code~~, ~~you will have a better shot at fixing~~ the ~~problem~~.		* On the other hand, understand assembly if you're doing micro-optimizations. Profilers will tell you what line your problem is on according to the symbol database, but that line can expand out into hundreds of instructions, only one of which is the problem. Understanding assembly will let you know if that instruction is the divide, or actually the memory access fetching the value to be divided.

Doug Linden at 16:12, 21 June 2007

2007-06-21T16:12:03Z

← Older revision		Revision as of 09:12, 21 June 2007
Line 3:		Line 3:
	Secondly, I would recommend reading the following article - if only to have an understanding of terminology that will be used. http://en.wikipedia.org/wiki/Performance_analysis		Secondly, I would recommend reading the following article - if only to have an understanding of terminology that will be used. http://en.wikipedia.org/wiki/Performance_analysis

	~~First things first~~: ALWAYS profile before ~~optimization~~.		Basic guidelines:
			* ALWAYS profile before and while performing optimizations. There are ALWAYS surprises, and the hot spot isn't always exactly where you think it is. Plus, a good profiler will help you figure out exactly what your problem is - whether it's memory access, CPU.
			* Iterate frequently. Don't do one profile, write a week's worth of code, then write another profile. As you change the code, the hot spots will change.

	= Profiling =		= Profiling =
Line 23:		Line 25:

	= Optimization =		= Optimization =
			* Obviously, always optimize based on the results of a profile.
	* Always try to do algorithmic and architecture-based optimizations before code optimizations.		* Always try to do algorithmic and architecture-based optimizations before code optimizations.
	* Memory and cache considerations are often MUCH more important than instruction count. This is a relatively recent phenomenon. On some architectures, you can run dozens of instructions or more in the amount of time that it takes to fetch data from main memory. Thus, when optimizing, you may want to actually pay more attention to how your algorithms access data than the number of instructions that they use.		* Memory and cache considerations are often MUCH more important than instruction count. This is a relatively recent phenomenon. On some architectures, you can run dozens of instructions or more in the amount of time that it takes to fetch data from main memory. Thus, when optimizing, you may want to actually pay more attention to how your algorithms access data than the number of instructions that they use.
	* Don't write assembly unless you absolutely have to. It's not easy to make cross-platform, and unless you are REALLY good, compilers are often better than you are. If you need to, restructure the C/C++ code to make it more clear to the compiler what you are attempting to do.		* Don't write assembly unless you absolutely have to. It's not easy to make cross-platform, and unless you are REALLY good, compilers are often better than you are. If you need to, restructure the C/C++ code to make it more clear to the compiler what you are attempting to do.
			* On the other hand, understand assembly if you're doing micro-optimizations. Profilers will tell you what line your problem is on according to the symbol database, but that line can expand out into hundreds of lines of assembly, only one of which is the problem. If you can figure out what assembly corresponds to what in the line of C code, you will have a better shot at fixing the problem.

Doug Linden at 16:04, 21 June 2007

2007-06-21T16:04:29Z

← Older revision		Revision as of 09:04, 21 June 2007
Line 15:		Line 15:
	** For the above reason, I generally prefer time-based sampling profilers over instrumented call-graph profilers. The one disadvantage of most time-based profilers is that they don't generally have call-chain information (they only keep track of the function where CPU time was spent, not where it was called from) - although at least one profiler (Shark on OSX) is capable of doing this without performance degradation).		** For the above reason, I generally prefer time-based sampling profilers over instrumented call-graph profilers. The one disadvantage of most time-based profilers is that they don't generally have call-chain information (they only keep track of the function where CPU time was spent, not where it was called from) - although at least one profiler (Shark on OSX) is capable of doing this without performance degradation).

	~~= Optimization =~~
	* Always try to do algorithmic and architecture-based optimizations before code optimizations.
	* Memory and cache considerations are often MUCH more important than instruction count. This is a relatively recent phenomenon. On some architectures, you can run dozens of instructions or more in the amount of time that it takes to fetch data from main memory. Thus, when optimizing, you may want to actually pay more attention to how your algorithms access data than the number of instructions that they use.
	* Don't write assembly unless you absolutely have to. It's not easy to make cross-platform, and unless you are REALLY good, compilers are often better than you are. If you need to, restructure the C/C++ code to make it more clear to the compiler what you are attempting to do.

	A list of profilers that we've used at Linden:		A list of profilers that we've used at Linden:
Line 25:		Line 21:
	* VTune (Windows) - sampling and call graph profiler. The UI is terrible - but there aren't many other sampling profilers available on Windows.		* VTune (Windows) - sampling and call graph profiler. The UI is terrible - but there aren't many other sampling profilers available on Windows.
	* GlowCode (Windows) - instrumented call-graph profiler, but a lot faster than typical - so it runs in near real time. If you want call chain information on Windows, this may be the way to go.		* GlowCode (Windows) - instrumented call-graph profiler, but a lot faster than typical - so it runs in near real time. If you want call chain information on Windows, this may be the way to go.

			= Optimization =
			* Always try to do algorithmic and architecture-based optimizations before code optimizations.
			* Memory and cache considerations are often MUCH more important than instruction count. This is a relatively recent phenomenon. On some architectures, you can run dozens of instructions or more in the amount of time that it takes to fetch data from main memory. Thus, when optimizing, you may want to actually pay more attention to how your algorithms access data than the number of instructions that they use.
			* Don't write assembly unless you absolutely have to. It's not easy to make cross-platform, and unless you are REALLY good, compilers are often better than you are. If you need to, restructure the C/C++ code to make it more clear to the compiler what you are attempting to do.

Doug Linden: New page: First, this article assumes that you're working with an existing and essentially complete piece of code or product that you want to optimize. However, if you are working on performance cr...

2007-06-21T16:03:39Z

New page: First, this article assumes that you're working with an existing and essentially complete piece of code or product that you want to optimize. However, if you are working on performance cr...

New page

First, this article assumes that you're working with an existing and essentially complete piece of code or product that you want to optimize. However, if you are working on performance critical code (rendering code falls into this category, for example), you will have wanted to start thinking about performance long before you reach this stage. A good article to read is this one: http://www.acm.org/ubiquity/views/v7i24_fallacy.html

Secondly, I would recommend reading the following article - if only to have an understanding of terminology that will be used. http://en.wikipedia.org/wiki/Performance_analysis

First things first: ALWAYS profile before optimization.

= Profiling =
* Choosing a test case:
** If possible, have a reproducible test case in your production environment.
** A good test case may not be steady-state. It may be better for your test case to reproduce the production environment than have it be repeatable.
** If you are performing micro-optimizations that you can't reproduce, generate a good synthetic test case that heavily exercises what you're working on, and optimize that.

* Choosing the profiler:
** If a profiler is slowing down your application, it is probably distorting your results. This is usually because the profiler is adding/running significant amounts of instrumentation which is doing a lot of work. In addition, in network and graphics applications, significant performance degradation can significantly impact things such as the amount of network traffic recieved and the amount of time spent blocking waiting for the GPU.
** For the above reason, I generally prefer time-based sampling profilers over instrumented call-graph profilers. The one disadvantage of most time-based profilers is that they don't generally have call-chain information (they only keep track of the function where CPU time was spent, not where it was called from) - although at least one profiler (Shark on OSX) is capable of doing this without performance degradation).

= Optimization =
* Always try to do algorithmic and architecture-based optimizations before code optimizations.
* Memory and cache considerations are often MUCH more important than instruction count. This is a relatively recent phenomenon. On some architectures, you can run dozens of instructions or more in the amount of time that it takes to fetch data from main memory. Thus, when optimizing, you may want to actually pay more attention to how your algorithms access data than the number of instructions that they use.
* Don't write assembly unless you absolutely have to. It's not easy to make cross-platform, and unless you are REALLY good, compilers are often better than you are. If you need to, restructure the C/C++ code to make it more clear to the compiler what you are attempting to do.

A list of profilers that we've used at Linden:
* Shark (Mac) - my preferred profiler right now. Sampling profiler, but it still manages to have call chain information. Great UI. Unfortunately, can't use it for everything, as it's Mac only, and graphics stuff is very different on the Mac vs. PC.
* oprofile (linux) - another sampling profiler. No UI, no call chain information. However, very easy to use on Linux.
* VTune (Windows) - sampling and call graph profiler. The UI is terrible - but there aren't many other sampling profilers available on Windows.
* GlowCode (Windows) - instrumented call-graph profiler, but a lot faster than typical - so it runs in near real time. If you want call chain information on Windows, this may be the way to go.