Is there a faster hi resolution timer for diy profiling

[Willy Denoyette [MVP]]

yeah strange, maybe some who knows the internals can shed some light on
this?

You need to check your project/debug attributes for this project.

without actually knowing where the code is spending its time during
those 9000 clock cyclces its hard to know whats cuasing it.


yes good point, however I wanted to make sure the realease build was
clean.
Theres little difference in the run time beteween debug and release.

I was only looking for the most time consuming parts of the code
I didnt expect a 20 times increase in time just becuase of this timer
tho lol, the increase occurs in the release or debug version,
purly determined by the debugegr being attched or not.

thanks very much for your help finaly got a workable solution anyway
Colin =^.^=

The debug version of the code I posted, takes 230-350 cycles (that is the
time needed to service that rdtsc function)when running in the managed
debugger (IDE VS2008) on my box.
Which is quite normal, because the CLR has to signal the transition into
unmanaged code to the debugging engine (and obviously to the attached
debugger).

Willy.

 

[colin]

....

You need to check your project/debug attributes for this project.

Ive looked in all the settings and theres hardly any at all that look like
they might make a difference,
espcially compared to the options for c++,
in the build options theres optimise code wich makes a slight difference.

there may well be options I havnt discovered yet,
I had to ask how to do 1 or 2 things so far only to be told you cant do
that,
then someone says its an option in a menu id never seen before by prerssing
"ctrl-d" + e

The debug version of the code I posted, takes 230-350 cycles (that is the
time needed to service that rdtsc function)when running in the managed
debugger (IDE VS2008) on my box.
Which is quite normal, because the CLR has to signal the transition into
unmanaged code to the debugging engine (and obviously to the attached
debugger).

so im seeing an increase of 30 times greater than what your seeing, maybe
it has to do with VS2005 express ?
im using .net2.0 although i cant see that making a difference,
I do notice however that there seems to be debug versions of the .net dlls

anyway Ive got my run time down from 3000 seconds to 20 seconds wich is
acceptable for now, there seems to be no single thing wich looks like it
could easily be optimised further, although some octal tree sectioning
<might> help.
but this is a complication il think of when ive done some other things,
and only if its realy necessary.

although the managed directx does seem to spend quite a while copying vertex
information,
wich is an array of structs,
I cant create an array of structs in advance becuse I dont know the size in
advance,
so I make a list wich it then has to convert to an array,
then copy it to the graphics device lol.
unfortunatly I cant make the struct array very big to start with becuase it
copies the whole array and complains if I tell it the size is smaller than
its length.

il probly try to work out the size in advance or something.

Colin =^.^=