How optimize this code ?

Mar 28, 2007 at 9:38am

How optimize this code ?

#31070
Mar 28, 2007 at 9:43am

Sorry I leave an error in the code:
” addend = f; ” must be removed…

#100409
Mar 28, 2007 at 4:44pm

Salut Thomas,

You are copying a LOT of data every time the perform method is called.
It would be better to use a “circular buffer”, which would only
require copying on top of the data that you want to replace.

For instance, using your example,

[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] would become
[0, 1, 2, 3, 4, 5, 6, 7, 999, 998, 997]. and then if the next three
samples were -1, -2, -3,
[0, 1, 2, 3, 4, -1, -2, -3, 999, 998, 997].

you understand? this requires unfortunately that all other externals
using the buffer know where the first sample is – not always possible.
but maybe you can make playback mxj~ objects that understand this
circular writing scheme.

Ben

On 3/28/07, Thomas Goepfer

wrote:
>
> Sorry I leave an error in the code:
> ” addend = f; ” must be removed…
> –
> MacPPC G4/G5 10.4.8
> Max/MSP 4.6.2
>

#100410
Mar 28, 2007 at 5:02pm

#100411
Mar 29, 2007 at 1:29pm

Thanks men !

-> Ben
With your method, the current frame is not always in the same place in the buffer…

-> Topher
Yes, I think it is possible to “arrange” the buffer only when I need, but it is not really what I want…!

I just want to test this algorithm in java. I know it is possible to simulate this with a classic record~ and a virtual position based on current position in the buffer~. But it was only to test…
I see that in Java we don’t have “low-level” method to manipulate array. To have big loop in perform() method is not a great idea, and the method System.arraycopy() is heavy…

Too bad…! (for me)

#100412
Mar 29, 2007 at 2:05pm

Thomas Goepfer wrote:
> Thanks men !
>
> -> Ben
> With your method, the current frame is not always in the same place in the buffer…

Which is what Ben was getting at by saying you’d have to make custom
read objects. In essence, to get around copying so much data every time
you maintain separate read and write pointers.

One alternative to writing a play object from scratch would be to have
the writing object output a read pointer which could be used as an
offset for a phasor driven reader (I think you could use pong~ to make
it wrap appropriately, but I may be wrong).

> I see that in Java we don’t have “low-level” method to manipulate
> array. To have big loop in perform() method is not a great idea, and the
> method System.arraycopy() is heavy…

arraycopy() shouldn’t be that bad – as Topher suggested, much of the CPU
hit may be associated with the msp-mxj boundary crossing when you call
poke() on the buffer (particularly if you’re moving lots of data about).

How much better is performance without the calls to poke()? How does
performance vary with buffer size?


Owen

#100413
Mar 29, 2007 at 6:44pm

true ben.
i guess we can’t really know unless we know the size of the buffer~
instance he is using!
i thought it might be relatively small but i am making an assumption
there.

separate read and write heads is probably a better idea than shifting
the whole buffer
everytime you want to prepend data.

t

On Mar 29, 2007, at 10:40 AM, Ben Nevile wrote:

>> i am curious about this as well. i think the performance is due to
>> the fact that you are doing the poke stuff
>> in a tite loop. JNI stuff has inherent overhead.
>
>
> my guess is that the problem is simply that he’s copying tens or
> hundreds of thousands of samples every time through the perform loop.
> Java, native C, crossing a bridge or whatever the case may be, that is
> going to be very expensive!
>
> Ben

#100414

You must be logged in to reply to this topic.