Through the analysis of my code I determined that the following is the slowest part of one of my algorithms:
| 1 | BITMAP* Transform(BITMAP* in) |
| 2 | { |
| 3 | BITMAP* ret = create_bitmap_ex(8, in->w, in->h); |
| 4 | |
| 5 | for(int y = 0; y < ret->h; y++) |
| 6 | { |
| 7 | for(int x = 0; x < ret->w; x++) |
| 8 | { |
| 9 | int dispX = fn(x); |
| 10 | int dispY = fn(y); |
| 11 | |
| 12 | if(dispX < 0) |
| 13 | dispX = 0; |
| 14 | if(dispY < 0) |
| 15 | dispY = 0; |
| 16 | |
| 17 | if(dispX >= ret->w) |
| 18 | dispX = ret->w - 1; |
| 19 | if(dispY >= ret->h) |
| 20 | dispY = ret->h - 1; |
| 21 | |
| 22 | ret->line[y][x] = in->line[dispY][dispX];//A |
| 23 | } |
| 24 | } |
| 25 | destroy_bitmap(in); |
| 26 | return ret; |
| 27 | } |
Removing the statement A makes the code run 10x faster. Am I doing this correctly? Both bitmaps are memory bitmaps.
]]>Have you tried compiling your code with -O2 or whatever optimizations your compiler uses? If accessing memory slows your code way down this may not help much, but then nothing would I suppose.
]]>Well, consider that you're allocating memory for a new bitmap every time you run this routine, and you're calling fn() twice for every pixel. Depending on what fn() does, that might be what's holding it up. But the bitmap allocation could be slowing it down too.
If you could describe the effect you're trying to achieve we might be able to come up with an alternate method of doing it that would be faster.
--- Kris Asick (Gemini)
--- http://www.pixelships.com
Well, this is sort of embarrassing... Indeed the equalization does not take any time at all, and the bottle neck actually occurs in the fn function... Apparently, when I remove the equalization statement(marked A in the code) the optimization routine of the compiler removes the calls of the fn(), thus leading me to believe that it was actually the equalization that was at fault. I discovered this by manually removing the calls to the fn and then testing whether the removal of the equalization did anything... It did not.
The fn indeed needs to be optimized, but that is a question for another time.
Thanks...
]]>