• Is the bind used to partially apply the function and 'store' it in a variable

    Yes - exactly as @JumJum says - you're basically eliminating the parsing step, which is the slow bit in Espruino.

    In your approach, setting pins with a register limits other solutions.

    I'm totally happy to have something like this at the top of shiftOut so you can still have your fast I2S implementation:

    [#ifdef](http://forum.espruino.com/searc­h/?q=%23ifdef) ESP32
      if (pins.length<=8 && clk && jsvIsFlatArray(data) && etc...)
        return esp32_I2S_implementation(...);
    [#endif](http://forum.espruino.com/searc­h/?q=%23endif)
       // original register-based code
    

    The thing I don't like is creating a duplicate API for the same thing if there isn't a good reason. Having two similar APIs just confuses people, gives us more stuff to maintain, and ultimately means that instead of one, optimised solution we have two partially optimised solutions.

    If we can make the existing shiftOut fast, existing code that uses it (like LPD6416) should benefit as well.

    If there really is something in shiftOut's API that makes it too slow that's different, but am I right in thinking that as far as we've found out so far:

    • Currently, shiftOut is quite fast on STM32, less so on other platforms
    • With the branch I posted (and maybe a few fixes) it should be fast on all platforms, but not as fast as @JumJum's test code
    • So far the biggest reason we're sure of for the difference in speed seems to be direct memory access vs jsvIterateCallback?

    So if we can merge my tweaks and fix jsvIterateCallback we should be within a few percent of @JumJum's implementation, and then maybe we can add the special case for I2S to really speed things up for ESP32 in the right cases?

About

Avatar for Gordon @Gordon started