Optimizing

[rana]

Hi pete,

hope you are doing well... I was hoping you can give me on advice on the following scenerio, as it depends a lot on how FSUIPC handles request.

I am not near my code, or your documentation, so I will use some fictional addresses.

Assume, I need to do read the following 3 locations - &H1 (1 byte), &H3 (1 byte), and &H5 (4 byte)... normally I would do 3 read, and 1 process, however looking how close the locations are, would it be faster to:

do 1 read (8 byte) and 1 process.

I couldn't do an accurate timing, as FS does make my result flactuate a lot. But I assume as FSUIPC has to translate the address to real memory location, even reading unneccessary bytes for one read, may be faster than multiple reads.

Thanks a lot in advance.

[Pete Dowson]

Assume, I need to do read the following 3 locations - &H1 (1 byte), &H3 (1 byte), and &H5 (4 byte)... normally I would do 3 read, and 1 process, however looking how close the locations are, would it be faster to:

do 1 read (8 byte) and 1 process.

Yes, it can be a little faster, but it depends. If the three locations are truly contiguous in some memory somewhere in FS, then it will be a little faster. By comparison with the process switch invoked by the Process call itself, this won't be measurable -- but, yes, undeniably it has to be a little faster.

However, if the locations really refer to locations in different modules in FS, then there is actually extra code execution needed for FSUIPC to split the request up again.

I'm afraid that, in general, there is no way for you to know which way it might be. In FS98 it would all be contiguous (well, at least till 0x1FFF in GLBALS.DLL, then contiguous again but in FSUIPC memory for the rest). In FS2000 quite a lot is still continuous, but it gradually gets less and less so.

I couldn't do an accurate timing, as FS does make my result flactuate a lot.

The time to change process will vary by more than the few microseconds taken by the extra data processing, assuming there would be any, so I don't think you could measure it at all. Even using the more direct module access from inside FS, you are dependent on other things going on.

Incidentally, it most certainly used to be much more efficient to coalesce adjacent variables for requests through WideFS -- even if sometimes this meant including some data you didn't really need. This was because the whole block was sent, verbatim, over the Network. However, that was long ago changed. Now WideClient automatically does the coalescing for you, and then compresses the data before transmission.

So, all in all, don't worry about it. What you lose on the swings you gain on the roundabouts! :wink:

Regards,

Pete