>
Two things:
1) When you post code like this, post the whole damn file. Having to write
it out is a pain, especially when you have to guess what namespaces where in
use, which leads me to
2) When you use an assembly or class that isn't part of the framework,
*ALWAYS* mention it and provide a link(or include it if appropriate). It
irks people less. The HiPerfTimer I found *doesn't* work with your code, so
for the moment I am giving up on this and moving on.
In response to your 'Two Things'
1.) "...post the whole damn file" - really ?!?!? It just happens that
the 'whole damn file' is littered with snippets of code that would
probably confuse you, and would never link since they reference many
non .NET assemblies. OK I admit I could have yanked the code off into
its own project and given the entire listing like that, but, surely
you could just as easily have done that if you were remotely
interested in the issue. The code as presented illustrates the issue
without the burden of non-relevant code. Get off your high horse.
2) "When you use an assembly or class ..." Wow, HiPerfTimer gives you
an unresolved symbol ? Comment it out ! I agree you might be
slightly inconvenienced, but if you are interested in the issue, it's
pretty insignificant. Its use is obvious, you probably already have
your own High Performance Timer class you could easily slot in - if
not here it is
using System.Runtime. InteropServices ;
class HiPerfTimer
{
[DllImport("Kern el32.dll")]
private static extern bool QueryPerformanc eCounter(out long
lpPerformanceCo unt);
[DllImport("Kern el32.dll")]
private static extern bool QueryPerformanc eFrequency(out long
lpFrequency);
private long start, stop, freq;
// Constructor
public HiPerfTimer()
{
start= 0;
stop= 0;
if (QueryPerforman ceFrequency(out freq) == false)
{
// high-performance counter not supported
throw new System.Exceptio n("Performanc e Counter not
supported - bizarre !");
}
}
// Start the timer
public void Start()
{
QueryPerformanc eCounter(out start);
}
// Stop the timer
public void Stop()
{
QueryPerformanc eCounter(out stop);
}
// Returns the duration of the timer (in microseconds)
public long usec
{
get
{
return (long)(((double )(stop - start) / (double) freq
)*(double)10000 00);
}
}
// Returns the duration of the timer (in milliseconds)
public long msec
{
get
{
return (long)(((double )(stop - start) / (double) freq
)*(double)1000) ;
}
}
// Returns the duration of the timer (in seconds)
public double sec
{
get
{
return (long)((double) (stop - start) / (double) freq );
}
}
}
Again, the relevant code is present, in fact I have provided more code
than I really should have, I could easily have simply asked this
question
why is
BitConverter.Ge tBytes()
so slow compared to
byte[] myConvert(int val)
{
byte[] ret = new byte[4];
ret[0] = (byte)(val >> 24);
ret[1] = (byte)(val >> 16);
ret[2] = (byte)(val >> 8);
ret[3] = (byte)(val);
return ret;
}
But I decided to give you a framework for illustrating how slow it is.
As a side note: I realise you probably spent a long time becoming an
MVP, however, don't let it go to your head. There are plenty of us
out there who are also MVPs who are more humble than you, and don't
choose to advertise the fact by adding it to our signatures.
