slow process routine for reading in examples

[jano2358]

hi! In some example code the use of the function fill seems away from optimal (at least for me), the use I saw is this (and similar):

OSCMessage msg_in; int size; if( (size = Udp.parsePacket())>0) { while(size--) msg_in.fill(Udp.read()); <---- this part takes ~6mS to complete!

If we replace the last statement with:

uint8_t packetBuffer[UDP_TX_PACKET_MAX_SIZE]; Udp.read(packetBuffer,UDP_TX_PACKET_MAX_SIZE); msg_in.fill(packetBuffer,UDP_TX_PACKET_MAX_SIZE);

now this takes ~500uS to complete! This was measured in a arduino.org's Zero, UDP_TX_PACKET_MAX_SIZE was defined to 28 bytes.

[adrianfreed]

Hi, Thanks for the feedback.

How do you know the packet size would be 28 bytes?

On Mar 29, 2016, at 15:39, jano2358 notifications@github.com wrote:

hi! In some example code the use of the function fill seems away from optimal (at least for me), the use I saw is this (and similar):

OSCMessage msg_in; int size; if( (size = Udp.parsePacket())>0) { while(size--) msg_in.fill(Udp.read()); <---- this part takes ~6mS to complete!

If we replace the last statement with:

uint8_t packetBuffer[UDP_TX_PACKET_MAX_SIZE]; Udp.read(packetBuffer,UDP_TX_PACKET_MAX_SIZE); msg_in.fill(packetBuffer,UDP_TX_PACKET_MAX_SIZE);

now this takes ~500uS to complete! This was measured in a arduino.org's Zero, UDP_TX_PACKET_MAX_SIZE was defined to 28 bytes.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

[jano2358]

I just add a #define UDP_TX_PACKET_MAX_SIZE 28 right after #include this overrides the definition inside the library, is defined to 24 by default, but I got some fragmentation with my messages so I change it.