• Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 2569 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C language fread() extemely slow 130s compared to CCstudio GEL_MemoryLoad() 50s ...WHY?

AYM
Intellectual 310 points


I have an application on BIOS 5.41.10.35  DM6437 an am loading video imags with the C language fread().

This is incredibly s-l-o-w taking. Takes over 150 seconds to load a single 640x480 image over a JtagJet.

However, using  the Code Composer 3.3 gel command, GEL_MemoryLoad(), it take only 50 seconds.

What's up?  How can I get fread() to go fast?

I tried changing the BIOS RTDX buffer to 20k and put it in IRAM ...no change.

I tried changing the application C language fread() call to use 10k buffers, and still no change.

AYM

  • TI__Mastermind 45025 points

    Hi AYM,

    I believe the problem you are seeing is due to a known bug:

    SDSCM00032055 - setvbuf does not affect the internal buffering done in fwrite()

    The problem is that fwrite() calls write() for every 256 bytes of data.  The setvbuf function should allow you to configure this size to allow fewer calls to write().  However, it does not work.

    I believe the work around is to directly call write() instead of fwrite().

    I'll also ask that this post get moved to the compiler forums so they can comment on it.

    Steve

    ------------------------------------

    Details from the bug report:

    This problem was discovered while working with the DSP/BIOS Real Time File System.

    A test program is using the API fwrite() to write to NAND flash on the OMAPL137 platform.  I have observed that when calling fwrite() API with a buffer size of 1024 bytes, the write() API is called 4 times.

    This implies that the fwrite() API is only buffering 256 bytes of data before making the call to write().  This small buffer size causes extremely slow performance when trying to use fwrite() for large amounts of data on NAND flash.

    I have attempted to use the setvbuf() API in order to increase the buffer size used by fwrite() as follows:

    #define V_BUF_SIZE 1048576
    #pragma DATA_ALIGN(fileBuffer, 128u);
    char  fileBuffer[V_BUF_SIZE];

    setvbuf(f, NULL, _IOFBF, V_BUF_SIZE);

    however, the above call does not seem to do anything, as calls to fwrite() still result in a call to write() for every 256 bytes of data.

    please see attached C file containing my test case with calls to setvbuf and fwrite.

  • in reply to Steven Connell
    TI__Guru* 84285 points

    Even if you switch to write, you'll still hit the (roughly) 256 byte limitation.  You'd have to switch to a different implementation of write that does not go through the HOST device.  If speed is a concern, you probably want to use a non-HOST implementation of write, anyway.

    SDSCM00032055 can't be fixed with just a change the the compiler's RTS library; the debugger (CCS) would also have to be changed to allow a HOST buffer larger than 256, at which point the RTS library could be recompiled with a larger buffer size.

  • in reply to Archaeologist
    TI__Guru* 84285 points

    Hmm... Enhancement request SDSCM00041639, which is marked as implemented, is exactly what is needed.  This report says that the fix was released with CCS 5.3.0.242.  I'll note this in SDSCM00032055

    If you have CCS 5.3 or greater, what you'll need to do is modify the RTS source to change the value of BUFSIZ in stdio.h to something larger.  I'm sorry, I don't have good instructions on how to rebuild a custom library at this point.