Hi Z! I like the idea from TJ Edmister with the background change as easy to implement and easy to eyeball visual feedback of load, but let me tell you an anecdote: Once I upgraded from a 386 to a 6x86 CPU, but had no new VGA card yet. I played with an old Mandelbrot set program and was surprised that recompiling with floating point made little difference on the new CPU. But then I realized that the EGA card, running on ISA bus might be the bottleneck and indeed: Commenting out the code which SHOWS the Mandelbrot set, I could indeed measure that CALCULATING it was a lot faster in floating point than in fixed point compile :-)
Likewise, you could comment out parts of your fun project app, even if it makes the graphics look bad, just for the "fun" of knowing which parts take most of the graphics generation time. > but being able to detect instantly the weak place in program, which is > causing unnecessarily high CPU load (say: looping for a key without > any "pause 10 ms"), is the other useful thing. Then actually I'm... In DOS, you would probably only notice due to high CPU heat output. Because when you press the key, even the weak program still reacts immediately and most users are still happy. You could use some advanced cache statistics to see which parts of the program are accessed most often, some CPUs have very CPU model specific functionality for that sort of stuff. Also, you could try some interrupt counting TSR to see what is called how often, maybe Rugxulo knows one. Plus of course if you have the SOURCE of a weak program, or at least a binary debugging symbols, you can "profile" it: e.g. in Java, you let the program run and tell the Java profile function to check every X msec what your program is doing, by doing a snapshot of the current call stack. Gives nice useful stats, and you see which subroutines are active most of the time you look. You can also profile by counting EACH call, instead of looking every X milliseconds, but that makes the to-be-profiled program very slow. Of course it is true that you cannot formally predict where slower parts are, but I think running the program to measure is also nice. Eric ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
