Sign in to follow this  
Enokh

What exactly is ntdll.dll tan?

Recommended Posts

Hey all! Currently working on AI for an Abalone game and am now in the stage of optimizing the code so I can tell it to look more steps ahead. In any case, I used AMD's CodeAnalyst for a profiler and optimized the hell out of my code, resulting in a move being done by the AI in 15 seconds, to 2 seconds as of now. I just ran CodeAnalyst again and spent around a second clicking to move, and then let the AI determine the best move. It spent 80 seconds thinking (I upped the level to which it looks ahead) and immidietly closed the program. CodeAnalyst said that it spent 43% in a file called ntdll.dll, 30% of which in a function called "tan" (Is this the cos/sin/TAN function? Because I don't use it in my game) and another 40% in Abalone.exe. I already optimized what I could in my own code, why does it spend 43% of it's time in ntdll.dll? The game is made in MSVS 7, unmanaged C++, using MFC for the human interface. No external libraries at all, only my own code and MFC for the input. Of course I compiled in release mode with full optimizations on. Any ideas?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I don't know what "tan" does, but if you put a breakpoint there and examine the callstack when you hit the breakpoint, you could probably figure out what it does.

Share this post


Link to post
Share on other sites
Well, using Visual Studio's tool Depends.exe, I took a look at ntdll.dll, and it appears to contain all the C Standard Library functions, so tan would indeed be the tangent function. Somewhere, some function call you are making is in turn calling tan(). I suppose you could probably somehow manage to open up the DLL in an assembly view, and put a break point on the address indicated by Depends.exe (or probably CodeWarrior as well) for the tan() function. (0x00002E3E in my version of ntdll.dll) Then run the program in debug mode, and when it hits the breakpoint, have a look at the call stack. That'll let you know which function that you call eventually ends up calling tan().

[edit]As for a quick way to put a breakpoint in the DLL, you could just run in debug mode, and put a breakpoint on a function call into the DLL from your own code. Then step into the function call. This should take you into the assembly code of the DLL. Skip down to the tan() function's entry point as described above, add a breakpoint, and then continue running your program. It should soon break on the tan() call after that.[/edit]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this