Speed up CIN/DLL

[shoneill]

Since you have three wires coming out of your case structure with the data types U8, U16 and U32, LabVIEW has to decide on one and one only outside of the case structure.

Since forcing to U16 or U8 would lose data from the U32 version, a cast to U32 is performed.

If you keep ALL operations on the array within the case structure, you can get around this problem.  Otherwise you'll automatically have coercion.  You should be able to see this on the block diagram (small grey dot on the wire junction).

Shane.

[rolfk]

---

@anotherStefan wrote:
Hi Rolf,

well in fact I tried the MoveBlock function as well but with the same result. In the end I couldn't think of a faster way to move a block of memory then the way provided by memcpy if we stick to C. I suspect MoveBlock will call memcpy internally as well. There must be something I am missing. Regarding my assumption of the time loss as result of task switch: Please ignore that one as when copying larger blocks there is a linear increase in time. For a 4MB block of data the time needed on and average system (P4 2.6GHz) is around 200-250 ms! Hasn't anybody else encountered this problem before? I tried LV 5, 7 and 8 by now and always the performance was extremly poor...

---

At least in older versions of LabVIEW, MoveBlock was directly implemented using a loop. I agree that it shouldn't make any difference, but with nowadays C runtime libraries you don't really know how much of overhead there might be added by the use of exception handling and such.

Shane has explained to you where the real problem is. LabVIEW has to do coercion to the biggest of the datatypes to avoid loosing information if you wire different datatypes to the same case tunnel. LabVIEW is in fact a very strict typedefed language and that is one aspect why programming in LabVIEW is as easy as it is, but this ease has sometimes some implications that can bite you if you don't watch out.

I think if you need to have different source type images the most performant solution is to do the MoveBlock function yourself with the conversion between your source datatype and the destination U32 array directly in the loop. You won't get around some coercion for non-U32 arrays but at least LabVIEW does not have to create a new array in the diagram too, to do the coercion for you.

Something like:

typedef struct
{
     int32 len;
     uInt32 elm[0];
} *LU32ArrayPtr, **LU32ArrayHdl;

MgErr CopyImageArray(UPtr source, int32 len, int32 type, LU32ArrayHdl dest)
{
    MgErr err;
    int32 i;
    uInt32 *ptr;

    if (!source || !dest)
      return mgArgErr;

    /* Resize the dest array */
    err = NumericArrayResize(uL, 1, &dest, len);
    if (err)
       return err;

    switch (type)
    {
       case uB:
          for (i = 0, ptr = (*dest)->elm; i < len; i++, ptr++)
          {
             *ptr = *(uInt8*)source++;
          }
          break;
       case uW:
          for (i = 0, ptr = (*dest)->elm; i < len; i++, ptr++)
          {
             *ptr = *(uInt16*)source++;
          }
          break;
       case uL:
          for (i = 0, ptr = (*dest)->elm; i < len; i++, ptr++)
          {
             *ptr = *(uInt32*)source++;
          }
          break;
       default:
          return mgArgErr;
    }
    (*dest)->len = len;
    return noErr;
}

Rolf Kalbermatter

Message Edited by rolfk on 02-13-2006 08:53 PM

[anotherStefan]

Thanks a lot to both of you!

I think I will re-implement it like this to remain compatible (unfortunately this is a library):

The old VI with the 3 sub-VIs in a case-struct will internally be replaced by the CIN Rolf suggested, which should be much faster then my original implementation. The 3 internal VIs can be used stand-alone to achieve maximum performance for known data types. I really appreciated your patience!

All the best,

Stefan