evil, evilst: high cpu load about netpd-instruments HOT 3 CLOSED

Yeah, the high cpu load doesn't come from the OSC formatting nor from the network transport, but from [netpd-bus-order] in [i2mx]. Unfortunately, it does its job for all of the messages of the instrument, including the audio data, which ideally shouldn't be handled by [netpd-bus-order] at all.

from netpd-instruments.

[netpd-bus-order] now compares only the first 8 elements when doing list comparisons, which saves a lot of CPU cycles with large messages such as those generated by evil and evilst.

from netpd-instruments.

Turns out there is another optimization that saves a lot of CPU cycles when using evil and evilst: [netpd-funnel] uses [fudiformat] and [fudiparse] internally, so that [netpd-fifo] works for any kind of message. [fudiformat] seems to be quite slow, so it should be avoided when not needed. Since we're using [netpd-funnel] for byte lists only, there is no need to serialize data with [fudiformat].

from netpd-instruments.