Thomas Goepfer

how-optimize-this-code

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


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.

[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

[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

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.

[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.

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
>


With your method, the current frame is not always in the same place in the buffer...

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...

-> 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...

> 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

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 

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?

i guess we can't really know unless we know the size of the buffer~ 

i thought it might be relatively small but i am making an assumption 

separate read and write heads is probably a better idea than shifting 

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

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.

>> 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


How optimize this code ?