> Well, for one thing the response to the message sent out may not all
> be seen in one packet (it should, but life isn't that
> perfect) - particularly as this device works at 9600 Baud.
> That means the VB code will most likely need to make several calls
> into the control to get the complete response it expects.
Well, I suspect that the control should maintain a buffer, from which it reads
data upon request of the VB app, and to which the worker thread writes data,
upon arrival. Is that the case?
If all the VB end needs is the complete message, then it makes little sense
for it to poll for that data. Why not have the control fire an event when the
data read by the worker thread reaches the boundary of a complete message?
That's what events are for. This way, no polling occurs at all.
> I /do/ believe, based on your responses, that I could change the code
> to wait until it receives something or times out (it would be quite OK
> to tell the comms control how long to wait for a response before
> timing out) - this would certainly reduce the polling dramatically -
> but I'm afraid can't be done for now, that will have to be later.
Because the worker thread is doing the waiting, the UI thread (in which the VB
app runs) doesn't need to wait. Instead, it can just handle events raised
from your control, like I described above.
> But bear in mind that the VB code is polling the /control/ to see what
> it has in its RX buffer - it is not directly polling the comms system.
> That. of course, is handled by the receive thread waiting for an
> event. So the polling is not exactly what I suspect you are thinking.
> It is, however, probably still wasting some processor time.
That's far more efficient that what I originally thought (polling the comms
system) because the latter needs a kernel-mode switch which costs more than
1,000 CPU instrcutions on x86 (IIRC). However, if you use events, there will
be *no* polling at all.
> But the problem I have to ask is, why is that exact same polling
> method slower on XP than on 98 (if that is where the bottleneck
> occurs)? This is what I'm trying to find out, most importantly.
> Although I do want to know if there's a more efficient way on NT
> systems, I mean a way that is unique to NT architecture that has been
> specifically designed as an improvement over non-NT systems, rather
> than just using an inefficient method in my code {:v)
Read: IOCP.
> Most of all, I want to know what causes XP to be slower for the same
> code.
That's the question the profiler is able to answer.
> Are you saying that IOCP can't be used on non-NT versions of Windows?
Yes. They are NT-specifc. Check out the docs for CreateIoCompletionPort( )
et al.
-------------
Ehsan Akhgari
List Owner: [EMAIL PROTECTED]
[ Email: [EMAIL PROTECTED] ]
[ WWW: http://www.beginthread.com/Ehsan ]
'I have done that,' says my memory. 'I cannot have done that' - says my pride,
and remains adamant. At last - memory yields.
-Beyond Good And Evil, F. W. Nietzsche
