   Modern Optimisation Methods
  I've encountered a large number of people who have told me something along the lines of "don't micro-optimise your code, use a profiler and optimise the bottlenecks in your programs". I agree with this, however, this is usually all that I end up hearing from people. Once I've found a bottleneck, what can I do to reduce the choke? I'm looking for modern, high-level methods, rather than tweaking in assembly or on a low level.   
  1) Don't do whatever work it is you're doing inside that bottleneck.Finding a better algorithm is always step 1.2) Do the work more seldom.Not everything needs to be done every frame. See if you can build a work queue, and only bite off X items of the queue per frame (or 1/3 of the queue, or whatever).3) Organize data so it caches well.std::vector<> is almost always faster than std::list<>, unless you do a LOT of inserts and deletes in the middle. Group members that are accessed together, together. Make data structures as small as possible, so more of them will fit in the cache.;  Sounds good to me. :) Thanks   ;  Also, if you use 2 dimensional arrays, always access it a row at a time and not a column at a time because elements in the same row are stored together in memory. This will improve your cache hit rate.   ;  Actually, modern compilers may (or may not) do that for you anyway.   ;  So you have found a bottleneck, eh?Ok, let's get to work.1> Pull out the old O-notation.  Are you in the middle of an implicit of explicit loop?  The odds are you are.  What is the big-O notation speed of the loops you are in?  Often I find slow code is attached to O(n^3) and higher loops.2> So, it isn't an insane algorithm.  Well, double check anyhow.3> Are you doing something on millions of bits of data dozens of times per second?  Ie -- are you in per-pixel code?  If so, it is time to start low-level optimizing -- or doing the work less often.4> Neither of those?  Is the problem "doing UI action X is too slow?"  If so, think about doing the work for UI action X before the user asks for it, in a side thread.5> Did you already do it recently?  Maybe you are repeating some work that could be cached from the previous time you did it.6> Did you say "string manipulation on a 1 meg file"?  Many string algorithms assume that the string is short.  Repeatedly calling strlen on a extremely long string causes serious O(n^2) problems.  I told you to double check your big-O notation.  Writing more careful string manipulation code can help here.7> How many times per second did you say?  Maybe you really don't need to do this task every single frame.8> Message message, who'se got the message.  Mass-message spam can cause issues, especially when a simple "I've changed" message is sent out 1000 times per second, and each time it is sent results in a redraw of the tool.  Sometimes a message is best not sent immediately, and thus chunking up duplicate messages....Once you find slow code, start thinking about how you would have written it faster.  Test these changes in a step by step manner, making sure each step actually makes it go faster.;Quote:Original post by NotAYakk8> Message message, who'se got the message.  Mass-message spam can cause issues, especially when a simple "I've changed" message is sent out 1000 times per second, and each time it is sent results in a redraw of the tool.  Sometimes a message is best not sent immediately, and thus chunking up duplicate messages.This one had never occurred to me. :o Thanks, you probably saved me a headache in future. :);Quote:Original post by Leo_E_49Quote:Original post by NotAYakk8> Message message, who'se got the message.  Mass-message spam can cause issues, especially when a simple "I've changed" message is sent out 1000 times per second, and each time it is sent results in a redraw of the tool.  Sometimes a message is best not sent immediately, and thus chunking up duplicate messages.This one had never occurred to me. :o Thanks, you probably saved me a headache in future. :)This is corellary to hplus's "2) Do the work more seldom" - in this case, the redraw.  Message batching is one way to accomplish this (as NotAYakk suggests).  For my recent irc::console class a dirty flag with a manual redraw seemed simplest - I was polling it for i/o anyways, so polling the dirty flag for redraw at the same time was trivial.  This brought console response time from "okay" (would be an issue during large netsplits) to "pwnzors" (in need of no further optimization).   ;  Concerning the graphic part, you can have a look at both Nvidia and ATI website, which have a developper section holding quite a few useful powerpoint/pdf presentations.You'll find a lot of good hints about effectively using the graphic hardware. If ATI/mVidia doesn't know best how to, then who does :)http://www.ati.com/developer/http://developer.nvidia.com/page/home.htmlLearn how to use nvPerfHud (or it's ATI counterpart if there's one ?)Good luck !Janta   